How can I …

Develop a DNP3 RTU system with

M340 NOR0200H module?

System Technical Note

Wide area automation system

Design your
architecture

1
The STN Collection
The implementation of an automation project includes five main phases: Selection, Design,
Configuration, Implementation and Operation. To help you develop a project based on these phases,
Schneider Electric has created the Tested, Validated, Documented Architecture and System Technical
Note.
A Tested, Validated, Documented Architecture (TVDA) provides technical guidelines and
recommendations for implementing technologies to address your needs and requirements. This guide
covers the entire scope of the project life cycle, from the Selection to the Operation phase, providing
design methodologies and source code examples for all system components.

A System Technical Note (STN) provides a more theoretical approach by focusing on a particular
system technology. These notes describe complete solution offers for a system, and therefore support
you in the Selection phase of a project. The TVDAs and STNs are related and complementary. In
short, you will find technology fundamentals in an STN and their corresponding applications in one or
several TVDAs.

Development Environment
Each STN 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 while also addressing growing energy management requirements. Within a single environment,
measured energy and process data can be analyzed to help build an optimized plant.

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 and international safety
laws and regulations.

Readers are considered to already know how to use the products described in this System Technical Note (STN). This STN
does not replace any specific product documentation

2
Table of Contents

Quick Start Guide .....................................................................4

1. Introduction...........................................................................5
1.1. Purpose ........................................................................................................................................................ 5
1.2. Introduction to the RTU System ................................................................................................................... 5
1.3. Challenges.................................................................................................................................................. 11
1.4. Prerequisites .............................................................................................................................................. 11
1.5. Methodology............................................................................................................................................... 12
1.6. Limitation ................................................................................................................................................... 12
1.7. Presentation of the example project ........................................................................................................... 13

2. Selection..............................................................................15
2.1. Selection Criteria ....................................................................................................................................... 15
2.2. Selected Architectures ................................................................................................................................ 16

3. Design..................................................................................20
3.1. RTU system design ..................................................................................................................................... 20
3.2. RTU services design ................................................................................................................................... 22

4. Configuration ......................................................................27
4.1. M340 PAC setup ........................................................................................................................................ 30
4.2. Vijeo Citect setup ....................................................................................................................................... 39
4.3. Web Designer setup (Optional) .................................................................................................................. 48

5. Implementation ...................................................................53
5.1. M340 PAC .................................................................................................................................................. 53

6. Operation.............................................................................55
6.1 SCADA ........................................................................................................................................................ 55

Appendix .................................................................................57
Abbreviations .................................................................................................................................................... 57

3
 Quick Start Guide

Quick Start Guide

The goal of this System Technical Note (STN) is to provide recommendations, guidelines, and
examples to help users in different roles setup/operate/maintain an

RTU system with M340 NOR0200H module.

To get the most out of this STN, please consider the following suggestions:

- If this is the first time you are using the RTU system, we recommend that you read the entire
STN before proceeding.

- If you are already familiar with RTU technology and want to define a solution for your
application, you can start at Chapter 2.

- If your solution architecture is defined and you want to setup your application, you can start
at Chapter 3.

4
 1-Introduction

1. Introduction

1.1. Purpose

The purpose of this STN is to provide recommendations to design an RTU (Remote Terminal Unit)
system with Schneider Electric modular RTU solution, which will use a M340 PAC based modular RTU
system and Vijeo Citect SCADA on DNP3 Telemetry protocol.

To answer the customer requirements of the RTU application, this STN will introduce the main RTU
services which are supported by M340 PAC based modular RTU, such as transmission, data
acquisition, time stamping, event management, alarming reporting, data logging, etc.

1.2. Introduction to the RTU System

In the beginning of the document to help users get an overview of the RTU application, we will
introduce:

- What is an RTU system?

- Telemetry protocols

- RTU market and customer requirements

- RTU device categories

- M340 PAC Based modular RTU solution

 What is an RTU?

An RTU, (Remote Terminal Unit) is an electronic device which operates as a stand-alone data
acquisition and control unit that interfaces with the central station to a Telemetry SCADA or
distributed control system from a remote location.

RTUs aid in monitoring and controlling equipment by gathering and updating data from the
process equipment installed at remote locations. They then pass data onto the central station
through various different communication means (LAN, WAN, Radio, modem connections).

Along with the communication connection with the central station, there can be communication
connections with other RTUs. The RTU can also act as a relay station (store-and-forward
station) to another RTU, a facility which may not be accessible from the central station. The key
facilities also include direct updating of configuration and control programs from the base unit,
as well as being configured locally by an RTU programming unit.

5
 1-Introduction

RTU and Telemetry systems allow addressing the needs of the water and waste-water, hydro power
and oil & gas industries, for which remote monitoring and control are critical to their large and
dispersed sites.

Telemetry Protocols such as DNP3 and IEC60870-5 are key communication means that allow the
remote measurement, monitoring, control and data transfer of infrastructures scattered over a wide
area, or that are hard to access from the central center.

Below is an example of an RTU system:

Example of an RTU system

An RTU system can provide typical services such as:

Remote communication

- With a SCADA system in charge of a central operator station (monitoring, alarm

reporting), central databases (alarm or data archiving)

- With other remote sites (coordination, synchronization)

- With on-call personnel (alarm signaling)

- With an engineering station (diagnostic, software maintenance)

6
 1-Introduction

Process Data acquisition, processing and storage

- Data exchange with field devices within the station using field buses or digital and
analog I/O

- Communication with other controllers and local HMI

- Event detection and management, event backfilling

- Time stamping, data logging, alarming according to application requirements.

 RTU protocols

Currently, in industry, there are several different protocols in use for the communication
between the control center (Telemetry SCADA) and RTU stations, including proprietary or
legacy protocols and now standard protocols.

The most popular standard protocols are DNP3 (Distributed Network Protocol version 3) and
IEC 60870-5-101/-104 (International Electro technical Commission).

The main interest of standard protocols compared to proprietary ones is that they ensure higher
level of interoperability with various third party devices.

DNP3 is dominant in North America, Australia, and UK, while IEC is a legislative requirement in
some European countries. It is also common in the Middle East. In most of Asia and South
America, both are used almost equally.

Both protocols provide similar application functionality.

They are both particularly suitable and reliable for “non permanent communications” (modem,
radio, etc…) low bandwidth data exchanges, as they provide high efficiency and robustness in
data transfer between SCADA systems and RTU devices.

They are basically “event driven” protocols (report by exception, unsolicited messaging, and
event management) as compared to traditional polling protocols, which help reducing and
optimizing data traffic whilst also being efficient for permanent communications.

They work over serial, modem and IP networks, serial lines, field-buses, LANs.

 RTU applications requirements:

RTU systems allow addressing the needs of the water and waste-water (WWW), hydro power
and oil & gas industries (O&G), for which remote monitoring and control are critical to their large
and dispersed sites.

For the various different applications the main requirements of RTU system can be described as
follows:

7
 1-Introduction

Main specific Requirements on remote stations:

requirements for
● "Ready-to-use" solutions for telemetry and pump monitoring
WWW applications ● Conformal coating in some applications (waste-water with
H2S)
● 100 ms or more time-stamped event management and clock
synchronization
Requirements on the communication infrastructure:
● Networks of up several hundreds of stations
● Powerful telemetry SCADA with communication scheduler
● Large choice of communication options, intensive use of
public networks and wireless communication
● Conformance to locally accepted standards (IEC 60870-5 in
Europe, MEA and SE Asia, DNP 3.0 in Americas /Australia )
● Modem management

Main specific Requirements on remote stations:

requirements for
● Extended temperature range
O&G applications ● Extra-low power, battery management, solar-powered
solutions,
● 100 ms or more time-stamped event management, and clock
synchronization
Requirements on the communication infrastructure:
● Long distance media: fiber, radio, satellite, etc
● Industry-standard protocols

Main specific Requirements on the remote stations:

requirements for
● 1 ms sequence-of-event recording and clock synchronization
Power applications ● High-availability options (substations)
● Power supply options for auxiliary power
● EMI immunity as defined by IEC 61850-3
● IEC 61850 emerging as "substation bus" (parts 5/6/7/8)
Requirements on the communication infrastructure:
● Industry-standard protocols for remote communication
including event reporting and time-stamping services

 RTU device categories :

The various different RTU devices found in the market can be split into the following main
categories:

- Field devices with embedded RTU functions

The RTU electronics is embedded in the same housing as the application-specific

sensor or actuator.

8
 1-Introduction

- Compact RTU:

Shoebox-type device, providing all communication and process I/O interfaces, as well
as customizable or programmable control capability. Compact RTUs can be used for
small size applications such as small pumping stations.

- Modular RTU:

It’s assembly of a base unit and extension modules according to application size and
specific requirements, supporting fully programmable IEC61131 control capabilities.
Nowadays the trend is to use more and more PAC based modular RTU for larger RTU
applications, such as large pumping stations and treatment plants.

This document will describe a M340 PAC based modular RTU solution. Other
STN and TVDAs will be dedicated to detail other solutions.

Before the introduction of the M340 PAC based modular RTU solution, the benefits of
PAC based modular RTU solution will first be introduced.

PAC Based modular RTU system involves offering a more integrated solution with
powerful and scalable processing capabilities and larger I/Os points, along with high
modularity and flexibility. PAC based RTU offers extensive features and modularity
suitable for RTU & Telemetry applications.

 M340 PAC based modular RTU solution:

The new M340 RTU offer can be used to design a PAC based modular RTU system to answer
to the requirements of the targeted segment. It supports main RTU features. Both IEC60870-
101/104 and DNP3 telemetry protocols are supported, however this STN refers only to the
DNP3 protocol, with theIEC60870-101/104 protocol to be detailed in a separate STN document
later on.

Following is the details introducing the solution.

There are three main parts in the M340 PAC based modular RTU solution,

- M340 PAC system

- M340 in-rack RTU module: BMXNOR0200H

- Vijeo Citect SCADA and DNP3 protocol driver

9
 1-Introduction

Below is the example of the M340 PAC based modular RTU architecture,

M340 PAC modular RTU solution architecture

This architecture will support 8 main RTU services:

- Transmission modes:

Serial mode: it supports RS232/RS485 serial communication.

Network mode: it supports Ethernet (TCP/IP) communication.

Note: If the distance between control room and remote sites is > 5Kms, the module can be
connected to the serial or IP modems as a remote connection with SCADA.

- Data acquisition:

The DNP3 protocol supports the following Data exchanges capabilities:

- Polled interrogations

- Report by exception

- Unsolicited responses

- Clock synchronization:

The module internal clock can be synchronized with the SCADA master via NTP server or
DNP3 time synchronization command.

10
 1-Introduction

- Time stamping:

The module supports time stamping with DNP3 protocol, and the time source can be taken
from the NOR module or the PAC CPU's real-time clock.

- Event management:

The NOR module manages a buffer of time-stamped events while connection is

not done with the SCADA master. The data which is stored in the NOR module's buffer can be
automatically added to the SCADA system, after communication is recovered.

- Data logging:

The module can store the historical data on an SD card.

- Email/SMS Alarming:

The module can send the alarm notification or reporting by email or SMS.

- Inter-Sites Synchronization

The local process can be synchronized with other remote site’s process, using Modbus TCP
protocol.

1.3. Challenges

For customers in industries that require PAC based modular RTU solutions mentioned above, the
challenges are:

 The type of remote communication: permanent vs non permanent

 The number of remote sites to manage

 The type of services required: event, alarming, data logging, time stamping
accuracy, etc

 The communication protocols specified: DNP3, IEC60870, etc

1.4. Prerequisites

Schneider Electric recommends that users have knowledge of the following systems:

 Schneider Electric PAC – M340 platform

 Schneider Electric software - UnityPro, Vijeo Citect and Web Designer

 RTU protocols – DNP3

11
 1-Introduction

1.5. Methodology

This STN explains the project methodology, which include the following phases: Selection, Design,
Configuration, Implementation and Operation. A step-by-step methodology is provided to create an
RTU application. Here is an overview of this method:

 Selection: This phase presents two selected architectures.

One is called “TCP/IP com” architecture, and the other is “serial com”
architecture.

 Design: This phase comprises two main parts:

 RTU system design: how to develop the hardware and software of the
selected architecture.

 RTU services design: how to develop the RTU services of the selected
architecture.

 Configuration: This phase explains how to set up the selected solution step by
step, it includes,

 How to set up the M340 PAC system with UNITY Pro software

 How to set up the Vijeo Citect SCADA system.

 Implementation: This phase explains the programming requirements:

 The PAC part explains how to implement the relevant sections.

 Operation: This phase presents the capabilities of the final SCADA application:

 How to use Vijeo Citect in order to monitor remote control architecture

1.6. Limitation

This document covers DNP3 based solutions, with IEC 60870-101/104 protocol to be covered in a
separate system guide.

Vijeo Citect SCADA is currently used to monitor and control the system, whilst in a future release;
Clear SCADA will also be used to develop a telemetry system.

It doesn’t support gateway function on NOR0200H V1.0 version. It means that the events which are
generated by other devices can’t be sent to SCADA through the NOR0200H module after fault back.

One module supports only one protocol and one port running at the same time on NOR0200H V1.0
version.

Maximum event’s buffer size is 10000 events.

12
 1-Introduction

1.7. Presentation of the example project

The recommendations and guidelines provided in this STN are generic for remote process
applications, and can be adapted to other applications such as oil and gas, power stations and so on.
However, we use the specific example of a drinking water plant to illustrate our methodology and
application. The following chapters will be demonstrating this example 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 located anywhere.

The following illustration represents the targeted application and telemetry services:

Internet

GSM

Internet

Internet Site2- Water Tower Pump

Site1- Drinking water station Pump

Example application of drinking water plant

13
 1-Introduction

Below is list of the telemetry services which can be offered by the NOR 0200H RTU module with the
PAC based RTU solution;

- DNP3 data exchanges based on report by exception

- Time synchronization via DNP3 or via NTP

- Time stamping of data, alarms and events

- Buffering of time- stamped events

- Automatic backfill of time-stamped events to SCADA

- Remote connection to PLC program via Unity Pro programming software

14
 2-Selection

2. Selection
This chapter presents two PAC-based modular RTU architectures for a water plant application. The
first (TCP/IP Com) uses Ethernet to communicate between SCADA and NOR. The second (Serial
Com) uses Serial Link.

2.1. Selection Criteria

Selected architectures must answer different needs of the RTU application, including:

- Usage: Define if this network should be connected permanently versus on

demand (very often this choice is related to where the installation is located). The
goal of the communication is to send a periodic report, to send an alarm or used
for a permanent monitoring).

- Distance: Define the length of the network (long distance > 5km or short distance
< 5km).

- Facilities: What are the available facilities at the remote site: PSTN line or
Ethernet (often in the factory), a copper line (in the workshop), a GPRS relay
(pump station), WifiMAX (for the pipe line).

- Performance: What is the performance required -fast to react on an event or low

speed to return a periodic report?

- Investment: What is the level of investment – do we want to reuse the existing

facilities or rent the materials?

- Safety/Availability: An important point in the network selection - what is the

safety level, safety for the network robustness (EMC), or safety for the encoding
network? The availability will keep the network continuously operational even if
one fault occurs on the device (infrastructure tunnel, oil, etc)

- Data logging/Duration: The major function in these architectures is to store

events with time-stamping or to store periodically some parameters all of which
transmitting data in shifted time to SCADA.

Above all mentioned needs, the main criteria are:

- The telemetry system topology: size, type of communication

- The RTU services required and the quality of services expected

15
 2-Selection

2.2. Selected Architectures

Two typical RTU system architectures will be described. One is using TCP/IP network architecture,
and the other one is Serial network architecture.
Note: in the TCP/IP network architecture, user can select the wired TCP/IP connection or wireless
TCP/IP connection. With the wired TCP/IP connection, the DNP3 protocol will be run on the BMX
NOR0200H Ethernet port. With the wireless TCP/IP connection, the DNP3 protocol will be run on the
Ethernet port with the modem dialed by itself, or on the serial port with the modem dialed by BMX
NOR0200H module.
This STN will select the wireless TCP/IP connection with the modem dialed by BMX NOR0200H as an
example of the TCP/IP network architecture.

TCP/IP network selected architecture description:

If we select the TCP/IP com architecture, there will be an ADSL modem connected to a PC at the
control room, and a GPRS/GSM modem connected to the BMX NOR0200H module at the remote
sites.
GPRS communication is used for data exchange with DNP3 Net protocol, FTP and e-mail services,
and inter-sites synchronization with Modbus TCP protocol.
GSM service is used to report alarms to a mobile operator via SMS.

As the GPRS/GSM dual-band modem can’t be running the GPRS and GSM at the same
time, the data exchange with the GPRS will be interrupted by the short message with the
GSM services. Before the short message is sent, the register of the enable GPRS needs
to be set 0. After that, the data exchange can be run again with the register set to 1.

Architecture1: TCP/IP com

16
 2-Selection

Serial com selected architecture description:

If the Serial com architecture is selected, then radio modems are connected to the PC within the
control room and to the BMX NOR0200H module at the remote sites.

With the radio modems, the data can be exchanged with DNP3 Serial protocol.

As there is only one serial port per module, only one modem can be connected to the module. So,
many RTU service can’t be supported in this architecture, which includes data logging, alarm report
and inter-sites synchronization services.

This architecture is suitable for permanent connection to exchange data between the control room and
remote sites.

Non permanent communications (PSTN, GSM) are not covered by this STN.

A dedicated STN can be prepared to describe this architecture and to illustrate how DNP3 services
(unsolicited and solicited modes) can be used.

Architecture2: Serial com

Trio datacom radio modem can be selected for use in Point to Multi Point
(MAS) data radio communication systems as well as Point to Point data links.
And it can be as a radio modem recommendation to users.

17
 2-Selection

Below is the supported RTU services list table for both selected architectures,

Now we will take the example application to describe how to select the architectures.

In the example application of the drinking water plant, there are four main locations, including:

- Site A: Control Room

- Site B: Mobile Operator

- Site C: Remote Site 1: Drinking water station

- Site D: Remote Site 2: Water Tower

D
A

C
B

The Application requirements are:

The telemetry system topology must comprise

- A Small application with one SCADA system used in Site A and two RTU devices
used in Site C and D,

- A Wireless connection between Sites A, C, and D.

The RTU services required and the quality of services expected are

- Events management supported, which include time synchronization, time

stamping and events backfilled,

- Remote sites (C, D) must be synchronized,

- Data logging files transferred via FTP

18
 2-Selection

These application requirements will be used to:

- Select a wireless connection telemetry system topology,

- Select all of the RTU services supported by BMX NOR0200H module supported

The TCP/IP com architecture can thereby meet the needs of the example application. Detailed
development information will be introduced in following chapters.

Below is the RTU services coverage of the selected architecture:

- Alarm report via SMS

- Data acquisition with
DNP3 Net protocol

- Event management, time

synchronization, time
stamping, events backfilled

- Alarm report with email

- Data logging transferred via

ftp service

- inter-site communications

Selected architecture- TCP/IP com architecture

19
 3-Design

3. Design
This chapter details how to design the TCP/IP com architecture in order to realize the RTU system and
services for the example application of a drinking water plant.

3.1. RTU system design

In order to design the RTU system within the drinking water plant, there are two main parts to be
designed, including:

- RTU SCADA design in sites A (control room) and B (mobile operator)

- RTU devices design in sites C (drinking water station) and D (water tower)

Below is an RTU system architecture designed to realize the RTU system within the drinking
water plant.

A
B
D A

C D
Drinking water plant

RTU system architecture

RTU SCADA design sites A (control room) and B (mobile operator):

 Use a PC installed with Vijeo Citect SCADA software at site A connecting to the
remote devices via an ADSL modem.

 Use a mobile phone to receive the SMS short message with alarm report in
B site.

RTU device design sites C (drinking water station) and D (Water tower):

 Use a M340 PAC system, and a M340 BMX NOR0200H module to design
modular RTU devices to monitor and control the sites C and D.

20
 3-Design

 Use the Serial port on the BMX NOR0200H to connect to SCADA with
GPRS/GSM modem, whilst running DNP3 Net protocol to exchange the data
between SCADA and devices with GPRS function. Design the event
management, data logging and e-mail alarm report services with GPRS function.
Design the remote sites (C, D) synchronized with GPRS function. Send SMS
alarm report with GSM function. Use M340 PAC application to switch the
functions between GPRS and GSM.

Below is an example of the GPRS/GSM modem design for the connection between Vijeo Citect
SCADA and BMX NOR 0200H module:

Internet
GSM

GPRS/GSM
modem

Example of the GPRS/ GSM modem connection

This STN selects the WAVECOM 1306B as the GPRS/GSM dual-band modem. Detailled GPRS/GSM
modem configuration steps will be introduced in the Configuration Chapter 4.

21
 3-Design

3.2. RTU services design

The following section will detail the design of RTU services with the selected TCP/IP com architecture.

There are 8 main RTU services supported, which include transmission mode, data acquisition, clock
synchronization, time stamping, event management, data logging, email/SMS alarm report and inter-
sites synchronization.

Service 1: Transmission mode – Data transmission between Vijeo Citect SCADA and the M340
NOR with ADSL\GPRS modem.

Service 2: Data acquisition- Data exchanges between Vijeo Citect and M340 NOR with DNP3 Net.

22
 3-Design

Service 3: Clock synchronization- Time synchronization by NTP server or DNP3 command.

Service 4: Time stamping- Time stamping management by DNP3 protocol.

23
 3-Design

Service 5: Event management- Event data backfilled with Vijeo Citect trend database.

Service 6: Data logging-Storing the historian data in the M340 NOR SD card.

24
 3-Design

Service7: Email/SMS Alarming

- reported by email.

- reported by SMS.

25
 3-Design

Service 8: Inter Sites Synchronization- Two remotes site are synchronized with Modbus TCP.

Use the GPRS modems to establish the communication channel between the two sites, with the
communication channel supporting running of the Modbus TCP and DNP3 Net protocol at the same
time. The DNP3 Net protocol can be used to exchange the data between the control room and remote
sites. The Modbus TCP protocol can be used to exchange data between a number of remote sites.

26
 4-Configuration

4. Configuration
This chapter provides information about how to build the selected architecture step by step, in order to
realize the RTU system and services detailed within the above chapters.

There are 2 main setup sections including:

- The M340 PAC setup

- The Vijeo Citect SCADA setup

Vijeo Citect SCADA setup

IP address: 192.168.1.122
Subnetwork mask: 255.255.0.0

M340 PAC setup

IP address: 192.168.0.181
Subnetwork mask: 255.255.0.0
IP address: 192.168.0.182
Subnetwork mask: 255.255.0.0

Static IP addressing is used in this example. Depending on the ISP (Internet Service
provider) contract, you can request static IP addresses instead of dynamic IP
addresses. In the case of dynamic addressing, a dynamic domain name system
(DynDNS) is required. Dynamic IP addressing is not covered within this STN.

27
 4-Configuration

Below is an overview of the TCP/IP com selected architecture setup methodology:

Start

Step1: UnityPro V5.0: UnityPro configuration + transfer

application to PLC

Step2: Web sites: protocol setup + variable export with .XSY file
+ GPRS/GSM modem setting.

Step3: UnityPro V5.0: variable import with .XSY file and PLC
programming with the RTU DDT data + transfer
application to PLC

Step4: Vijeo Citect: Create a new project,

Configure the communication,
Add variable and Trend variable,
Create new pages.
Realize the time synchronization, time stamping and
events backfilled services.

Step5: Web Designer: Setup Data logging service,

Optional Setup Alarm report (E-mail/SMS) service.

End

28
 4-Configuration

Before starting the configuration stage, we introduce below the software which will be used in the
selected architecture setup.

UnityPro V5.0

To setup M340 PAC hardware, variable,

@IP, programming, debug

Embedded Web sites

To setup DNP3 communication,

variable, events, and modem
configuration

Web designer

To setup data logging and email/SMS

alarm report RTU services

Vijeo Citect

To setup SCADA communication,

variables and graphics

29
 4-Configuration

4.1. M340 PAC setup

Step 1:
UnityPro V5.0: UnityPro configuration + transfer application to PLC

Create a new project and implement the following configuration:

The minimum version for UnityPro is V5.0.

In the PLC adjust the fields used for the variables.

Adapt the rotary switches according to the

configuration done for the IP@.

In the STN select STORED, IP@ is assigned by the

application.

The Maximum number of BMXNOR0200H can’t exceed 2

30
 4-Configuration

Configure the communication node:

Model family: Enable NTP service

Setting BMX NOR0200H

@IP: 192.168.0.181

Associate the configuration done with BMX NOR 0200H

Specific configuration for un-located variables:

Make sure the Data dictionary option is enable

when you design the PLC application.

Otherwise un-located variables may

not be mapped into RTU data points.

31
 4-Configuration

Open the Project Setting

Select Data dictionary

A compiled application consumes more memory when the Data

dictionary is included. Be aware of this memory issue when using
un-located variables in RTU solutions.

When your configuration is complete, you need to build your application save it as a STU file and
download it to the targeted PLC.

Build

Save as

Connect

Download

32
 4-Configuration

Step 2:
Web sites: protocol setup + variable export with .XSY file + GPRS/GSM modem setting.
When the computer is connected it is possible to access to the embedded website.

Click on Setup to
select and to
configure your
protocol.

To begin, you configure the Communication channel

parameters (protocol, network, @, status …).
Click on Channel parameters to open the screen below.

Select Add to configure your communication

33
 4-Configuration

Channel ID: 0 (value by default).

Protocol: DNP3
Network type: TCP-IP
Mode: Server (the Client is the SCADA)
IP@: SCADA @: 192.168.0.122
Port: 20 000 (value by default).
Client Count: 1 (value by default).
Status Reg Type: %MW
Status @: 0

Now, the DNP3 server channel is added in the module web site. After that is the variable setting in the
Data Mapping and Events pages.

It is recommended to keep the default configurations.

First select Data Mapping to design the type of
variables you need.
Before accessing the Data Mapping screen you need
to provide a USER NAME and PASSWORD by
default.
The user name and password are USER / USER

In this screen we define the type, point

number, CPU @, name …. etc of the
data used.
With the lift select the type and add it.

When you add the type, a Popup screen is opened

according to the type selected when you configure
the variable mapping.

34
 4-Configuration

0 - Address of the object

2 - Number of objects defined.
Un-located - Type of object used
0 - Start address used in PLC (no
meaning for un-located variable)
-Control_Level - Variable name of the
object
1 – Event Class (priority)
Module – Time stamping done in the
module.
3-3 – For the variation static and event

Variation: In DNP3 variation defines the format of the variable, which can be
represented in 16 / 32 / 64 bits, with or without status.

The Events are used to select the variables you want to store in a
buffer (up to 10,000 per client).

Select Events to design the type of variables used.

The Event store mode allows you to choose events stored - All or the
Most Recent.

35
 4-Configuration

Select Export/Import files to export the variables in a file (.xsy).

Then this file is used by UnityPro user to design the application.

Select Export Variable XSY file for unity and right Click
here to export the variable.
Give the name RemoteSite_C.XSY.

If the GPRS/GSM modem is used in the RTU application, below is the example of the WAVECOM
1306B modem setting.

Details on GPRS / GSM modem settings:

 Use for instance, the WAVECOM 1306B modem, which is recommended

GPRS/GSM dual-band modem.

 Insert the SIM card, then power, modem signal indicator light flashes to indicate
the network has been located.

 Command setup on the web page of the BMX NOR0200H module. Select
ONDEMAND connection mode, and the following COMMAND VALUE to control
the GPRS connection.

36
 4-Configuration

 Initialization AT command: ATE0Q0 & D0 & S0 & C0 & W

APN China Mobile, select 'CMNET', SMS SERVICE CENTER. Please fill out
different areas (area code + SMS center number 86). Username, password, plus
pin code required under the SIM card. Local IP address if provided by the
SERVER side, then fill in 0.0.0.0, or as appropriate to local needs.

 When the connection status is set to 1, the connection is established. Then

DNP3 Net, Modbus TCP protocol and other RTU services can be running.

After all of the settings with the web sites, the reset communication needs to be
implemented.

To reset the module, click on Reset Communication.

Rebooting the module is mandatory after each module

modification throughout the web site.

37
 4-Configuration

Step 3:
UnityPro V5.0: variable import with .XSY file and PLC programming with the RTU DDT data +
transfer application to PLC

Right click on Variables & FB instances

and import the files RemoteSite_C.XSY

Details on PLC programming with RTU DDT data will be detailed in the Implement Phase.

38
 4-Configuration

4.2. Vijeo Citect setup

Step 4:
Vijeo Citect: Create a new project, Configure the communication, Add variable and Trend
variable, Create new pages. Realize the time synchronization, time stamping and events
backfilled services.

To configure Vijeo Citect you must respect the following steps, all these steps are mandatory:

 Vijeo Citect release is Version 7.2 minimum, we must also install the DNP3R
driver Version 4.02.52 minimum.

 Create a new project called ‘Pumping_station’.

Open Vijeo Citect, in the window Citect Explorer

select My Projects Right click / New Project

Give a name Water_drink_plant_pumping_station.

We keep the configuration by default

- Tab_style_1

- Template resolution

- Color Background

 Configure the server used, Cluster, IO server, Trend server and create a new
user, name and role.

39
 4-Configuration

Open Citect project editor, and select the Tab Servers

Give a name and comment and Click on Add to memorize.

The next step is to create an IO server and a Trend server.

Now select the Tab System

Under System, open first Roles (in our example

without privilege), and after the User to define the
user.

40
 4-Configuration

 Configure the communication Boards, ports, IO devices, Citect.ini file.

This communication information can be

created either by the command Express
Wizard or manually one by one by the
windows Board, Port, IO Devices.

Here is the configuration of the board we

will use to communicate with the BMX
NOR 0200H though the driver DNP3.

Be careful when inputting the Special

Opt parameter; correct syntax is required:
-I[ip address] -P[port#] -T
Special opt: IP@ of the device (M340)
and the port used is 20000.

20 000 is the port configured (by

default) channel 0 in the web site.

Address: value for the parameter source

Channel0 session0.

DNPR: Protocol used

Vijeo Citect INI File Settings:

You MUST add the following DNPR parameters in the Citect.ini file (through the Computer Setup
Editor). For more details on the available parameters and their descriptions, please see the DNPR
documentation of Vijeo Citect.

41
 4-Configuration

The Citect.ini by default is located under:

..\documents and Settings\All Users\Application Data\Schneider Electric\Vijeo

Citect 7.20\Config

In this file it’s mandatory to assign an address to the SCADA:

[DNPR]

SCADAAddress=3 [The DNP Address Matches configuration for the SCADA in DNP3 Parameters]

 Create the variables Tags (Specific variables) and Trend Tags.

In the Citect project Editor select Tags and Variables Tags.

ADD the following variable, the link between the SCADA and
the module is done through the point number here: AI0.val
(specific to DNP3 protocol).

All the variables usable

with the DNP3 protocol
are detailed in the
documentation DNPR
Driver User information
and Design.
Here is an extract
according to the first
parameter configured.

With Vijeo Citect it’s possible to write either directly the variables with the
software, or through Excel using the following browser:

42
 4-Configuration

Provide the Master.Dbf location: Project’s name:

SCADA Tags:
D:\documents and Settings\All Water_Drink_
Variables
Users\Application Data\Schneider Plant_Pumping_Stati
Electric\Vijeo Citect 7.20\User on

In …/Application/DNP3_Application a file named: VC_variables.xls. This file provides

you all with all the information you need to fill the previous file variable.DBF.
At the end you obtain the result below:

Now we must create in Vijeo Citect all the variables used in the Trend.

In the Citect project Editor select the TAB: Tags

and Trend Tags.

And ADD the following variable

Configure an Event
Trend (only Event
trends are supported
for pushing Data and
Timestamps).

43
 4-Configuration

 Build your graphical page

In this STN project we are going to create 2 screens:

- Settling Screen (visualization of the settling process).

- Trend Screen (to memorize the variables).

- Screen Creation

Open the Citect Graphics Builder.

Select the Tag File and New, and then Page

to create a new graphical page.

- Settling Screen

The Style selected is: Standard and the Validate your choice with OK
Template normal.

44
 4-Configuration

This page is to realize the data exchange, time synchronization and time stamping services.

Here is the normal Template with the Standard Type.

Use DNP3 Write time

command to synchronize
the NOR internal clock.

Use DNP3 to exchange the data between Use DNP3 protocol time stamped the Alarm events
NOR and SCADA.

45
 4-Configuration

- Trend Screen

This page is to realize the events backfilled service.

Here is the Template Normal with the Standard Type.

Select Process Analyst.

Use Process analyst

to realize the event’s
backfilled service.

On the properties Click on Process Analyst View

and Add Pane then ADD Pen with an Analog value.

Below is the overview of the Pen setting page:

46
 4-Configuration

Select the TAB Connection and Link the Pen1 with the Trend
variable “Control_Level_0”.

Need select Trend type

When your graphical page is done, you must select

Tools and update page then save your page with the
name Trends

47
 4-Configuration

4.3. Web Designer setup (Optional)

Step 5: Web Designer: Setup Data logging service, Setup Alarm report (email/SMS) services.

Use the web designer project creation wizard, to setup NOR RTU service project.

After the creation of the project, use the unity .stu file to import the variables into the web designer
device part. The variables imported to web designer can be used for e-mail and data logging services.

48
 4-Configuration

If the variables need to be used in this service part, the persistent property
should be selected.

Data logging service is used to store the historian data in the BMX NOR SD card. When the control
room needs to read the logged data, it can be transferred to PC via an ftp client. The file can also be
opened by the Excel software.

Below are the setup steps required to realize the Data logging services with TCP/IP architecture:

Right click the services to add a new service.

49
 4-Configuration

Choose the service type, which include data logging and email.

Data logging service detail setup,

Detail setup parameters in the configuration tab,

• Table parameters: define the table name, and select the variables to monitor
the table status and enable the data logging.

• Log parameters: select either trigger or timer to log the data. In this STN the
timer is selected. This means that the log variables will be stored in the NOR
with each 500ms.

• Log variables: add the variable from the list for the data logging.

50
 4-Configuration

• Backup parameters: select either trigger or timer way to backup the table. In
this STN, the timer trigger is selected which means that the log file will be
backed up in NOR every 30 minutes.

The minimum interval of the backup time is 30 minutes. So, when using the trigger way,
the unity application trigger timer needs more than 30 minutes.

• Purge parameters: delete the table on the module’s ftp server when the trigger
signal is set.

FTP settings: It’s up to the ftp client to send the table to the other ftp server.

Detail setup parameters in the properties tab:

• Backup Parameters: Select trigger or timer to implement the
global backup if global backup is selected.
• Purge Parameters: Delete all the tables on the module’s ftp
server.

51
 4-Configuration

Email/SMS alarm report service is used to report the remote sites alarming data via email or SMS.

Below is the email/SMS alarm report detail setup:

Short message sending enable bit.

Detail setup parameters in the E-mails tab:

• Email description: In this part it includes
Identifier, Trigger, Destination, Subject,
Attachment and Contents for the email
setup. Above is an example for reference.
• Email List: Here are listed all of the email
items which are added in the web designer.

Detail setup parameters in the Properties tab:

• SMTP server: setup the information
of the SMTP server.
• Sender: Sender email address.
• Module: Maximum size of send
queue and retry time setup.
• Service: Service status variable.

52
 5-Implementation

5. Implementation
This chapter helps user to implement the M340 PAC’s RTU application with an example of a pumping
station within a drinking water plant.

5.1. M340 PAC

 Pumping station variables definition:

Select the variables which are associated to the BMX NOR module in the data editor, and to be used
within the program logic.

Alam[0]:Water_level_alarm
Alam[1]:Silt_evel_alarm

Control_Level[0]: Water_level_value
Control_Level[1]: Silt_levle_value
SCADAC_Command[0]: P1 command
SCADAC_Command[1]: P2 command
SCADAC_Command[2]: P3 command
SCADAC_Command[3]: P4 command

 Pumping station programming:

Below is the programming of the pumping station application:

Pumping station

Alarming

Water Level control process

53
 5-Implementation

 Debug with online mode:

After connecting with Vijeo Citect SCADA, you can find the RTU DNP3 protocol connection status in
the animation table of the UnityPro software with online mode.

The counters are shown how

many events are not sent to
the master.
%MW2, 3 => Binary_Input
%MW4, 5 => Binary_Output
%MW6, 7 => Analog_Input

54
 6-Operation

6. Operation
This chapter details how to operate the pumping station application with Vijeo Citect SCADA.

6.1 SCADA

Below are the results of the Vijeo Citect SCADA running pages.

 Pumping Station setting page:

Time Synchronization:
Use DNP3 write time command to synchronize the RTU module clock. The results of the
time synchronization can be checked with CPU real-time animation.

Pumping operation:
Pump 1 starting: water
level increase
Pump 2 starting: water
level decrease
Pump 3 starting: silt level
increase
Pump 4 starting: silt level
increase

Alarming operation:
Water level >18000: water level too high,
words changed to red, and time stamped
with DNP3 protocol.
Silt level >18000: water level too high, words
changed to red, and time stamped with
DNP3 protocol variable.

55
 6-Operation

 Event backfilled with Trend analysis page:

The behavior when disconnecting the SCADA is the following:

You are now able to observe events in backfill management in the case of a SCADA disconnection,
by removing the Ethernet cable or by stopping the SCADA.

After disconnecting the SCADA, the number of events increasing are visible in the BMX NOR module,
when the water level is changing (via Unity Pro Application).

Once the connection is re-established again, Events buffered in the NOR module will be automatically
backfilled to the SCADA trend database via the DNP3 protocol facility

After a period, the Trend viewer will show that the data backfill is achieved by completing the
missing data.

56
 Appendix

Appendix

Abbreviations

PAC – Programmable Automation Controller

SCADA – Supervisory Control and Data Acquisition

RTU – Remote Terminal Unit

SMS – Short Message Service

57
Schneider Electric Industries SAS

Head Office Due to evolution of standards and equipment, characteristics indicated in texts and images
in this document are binding only after confirmation by our departments
89, bd Franklin Roosvelt
92506 Rueil-Malmaison Cedex
FRANCE

www.schneider-electric.com Version 1.0 – 06/2011