f628ba4380896c1fbc0cb3e329f33ec7a7bdb51b.1

8/13/2019 f628ba4380896c1fbc0cb3e329f33ec7a7bdb51b.1

1/16

A supplement to PLANT ENGINEERINGnd Control Engineeringmagazines

A supplement to Control Engineeringnd PLANT ENGINEERINGmagazines


2/16

the #1 value in automationOrder Today, Ships Today!* See our Website for details andrestrictions. Copyright 2013AutomationDirect, Cumming, GA USA. All rights reserved. 1-800-633-0405

C-more

around your plant!Practical, Powerful and Priced Right

Our C-more remote HMI application,for iPad, iPhone or iPod touch, is

available on the App Storefor $4.99.

It provides remote access and control

to a C-more panel for mobile userswho have a wi-fi or cellular connection.

Clear TFT 65K color displays with6 to 15-inch screens(6-inch STN modelsalso available)

Analog touch screen for maximum flexibility

Easy-to-use software

starting at:

$540.00 u.s.EA7-T6CL-R ( w/serial port )

6 TFT Touch Panel

C-more touch panels in 6 to 15 screen sizes are a practicalway to give plant personnel easy access to controls and data.

Check out the powerful yet easy-to-use configuration software

by downloading a demo version at:

http://support.automationdirect.com/demos.html

C-more touch panel family:6-inch STN

grayscale

6-inch TFT

65,538 colors8-inch TFT

10-inch TFT12-inch TFT

15-inch TFT

Starting at:

$432(serial)$540(adds Ethernet)

Starting at:

$540(serial)$757(adds Ethernet)

$1,081 $1,727 $2,051 $2,484

8 to 15-inch units include both serial and Ethernet ports

Research, price, buy at:

www.automationdirect.com/c-more

C-more operator

touch panels offer:

ALL C-MORE PANELS INCLUDE:

Analog resistive touch screen with unlimited touch areas

One USB A-type and one USB B-type port

Serial communications interface

FULL-FEATURED MODELS ADD:

10/100Base-T Ethernet communications CompactFlash slot for data logging

REMOTE ACCESS AND CONTROL BUILT-IN

No Additional Hardware required. The C-moreRemote Access feature resides in all panels withEthernet support, and requires no option modules.Access real-time data or initiate an action on acontrol system from anywhere, any time.(Requires software and firmware version 2.4or later*, and an Ethernet C-more panel)

CONNECT TO CONTROLLERS WITH DRIVERS FOR:

All AutomationDirect programmable controllers Allen-Bradley - ControlLogix, CompactLogix,

MicroLogix Ethernet, SLC Series, FlexLogix,SLC 5/05 Ethernet

Modbus RTU and TCP/IP Ethernet

GE SNPX

Omron Host Link Adapter (C200/C500), FINS Serialand Ethernet

Selected Mitsubishi FX Series, Q Series

Siemens S7-200 PPI and S7-200/300 Ethernet(ISO over TCP/IP)


3/16

Applied Automation October 2013 A3

A4Using EtherNet/IP in process automation instead of fieldbus EtherNet/IP takes advantage of Ethernet commercial

technologies to surpass alternative solutions.

A9Improving motion network noise immunity

Automatic retry can double the noise immunity of real-time industrial Ethernet-based motion networks.

A12Selecting the right SCADA technology Modern SCADA technologies offer choices that satisfy

functionality and security requirements while improving

performance for remote users.

Contents

A9

COMMENT

Ethernet has come a long way since the

days of 10BASE5 and 10BASE2. While

editing the cover story for this issue, I

couldnt help remembering a job I had

in the early 1980s. I supervised an engineering

group that maintained the automated test equip-

ment, computers, and network on the plant floor.

Many of the challenges my group faced

involved keeping the network up. More than a

dozen printed circuit board (PCB) test stations

and as many repair/rework stations shared a

10BASE2 network. Throw in a couple of mini-

computers to manage the PCB pass/fail data-

base and generate reports for management,

and watch the network go down at least 15

times each shift.

This scenario is simple for the Ethernet

of today. For the 10BASE2 we had to use

in 1983, not so much. At least we could use

BNC T-connectors; they werent allowed with

10BASE5. Also, the maximum number of

10BASE2 nodes was limited to 30. And this was

a multidrop trunkno determinism meant data

collision city.

In addition to making10BASE2 and 10BASE5

virtually obsolete, Ethernet over twisted pair

simplified cabling and transmission issues.

Routers, switches, and gateways solved the

determinism and collision issues. And data

transmission speeds: comparing the 10 Mbit/sec

from back in the day with the 10 Gbit/sec that

Ethernet IEEE 802.3 can support today makes

me wish we had this technology 30 years ago.

The evolution that has made Ethernet the

dominant commercial network for nearly 40

years will continue to open doors for industries

that take advantage of the best that automation

has to offer.

The evolving Ethernet

Jack SmithEditor

A4On the cover

This photo shows part of a process plant makinghypoallergenic baby food using instrumentation, con-

trollers, and industrial managed switches on a singleEtherNet/IP network. Courtesy: Endress+Hauser


4/16

A4 October 2013 Applied Automation

Using EtherNet/IP in processautomation instead of fieldbusEtherNet/IP takes advantage of Ethernet commercial technologies

to surpass alternative solutions.

Since its invention in 1973,Ethernet has changed

the world. It will continue

to deliver the fastest data

throughput, improve the

architectures upon which

it is delivered, evolve into varying

electromechanical spectrums to meet

the next industry trend, and penetrate

down into the tiniest of microproces-

sors. Our world of process and fac-

tory automation is no exception to the

ever-reaching technological advance-

ments of this network.

Around 20 years ago, the process

automation market had proprietary

ways to meet the demands of remote I/O peer-to-peer

communications. These approaches were successful and

supportable, but users began to demand that their automa-

tion systems interface and share more data automatically

with their front office systems over Ethernet.

Automation vendors began connecting their control sys-

tems via Ethernet, but there was no workable way to deploy

device control requirements over a non-deterministic net-

work infrastructure like Ethernet. As process users started

to transition from traditional 4-20 mA analog devices and

demanded digital device communications, fieldbus networks

emerged to meet the demands that Ethernet couldnt.

Today, Ethernet communication has overcome many of

the disadvantages of previous years and established its

presence in field device communications.

In factory automation, Ethernet-based networks are

being used to connect robots, variable speed drives, and

actuators to automation controllers. In the process control

world, EtherNet/IP now connects flow meters, pressure

instrumentation, and similar field devices to distributed

control systems, programmable controllers, and hybrid

programmable automation controllers (see Figure 1).

While there is no network panacea, EtherNet/IP has

benefits that some fieldbus architectures cannot deliver.

EtherNet/IP:

Is easier to connect to a variety

of host systems

Can communicate with multiple

hosts simultaneouslyIs instantly familiar to anyone

with Ethernet experience

Can use all available Ethernet

tools and technologies

Can use quality of service

(QoS) to prioritize network traffic

Can use simple network man-

agement protocol (SNMP) to

monitor and manage the network

Has more network topology

options when switches are

deployed

Provides better support for wirelessdata transmission

Provides better security through the

use of standard Ethernet tools

Offers economies of scale that promise future gains

that are outpacing fieldbus.

This article explores these benefits.

Industrial Ethernet protocolsWithin the Ethernet frame, one can place almost any

application protocol. There is no one particular protocol

that serves all the needs of industry. Instead, application

protocols are like a tool chest, with users picking the ones

that support the demands of their particular automation

applications to provide the required performance, security,

and safety.

The focus for this article is on EtherNet/IP, the indus-

trial Ethernet protocol supported by the Open Device

Vendor Association (ODVA). EtherNet/IP uses the stan-

dard Ethernet frame as defined by IEEE 802.3 and uses

ODVAs and ControlNet Internationals Common Industrial

Protocol (CIP) application protocol library of objects.

The CIP application library can be deployed upon sever-

al different physical network architectures. This is a unique

benefit to users because there are no physical applicationinterfaces between the layers. This gives the CIP library

By Michael Robinson,Endress+Hauser

Figure 1: Process instrumentation with

EtherNet/IP connections, such as the

Coriolis flow meter shown in the photo, is

becoming more common as users realizethe benefits. Courtesy: Endress+Hauser

COVER STORY


5/16


almost seamless bridging and routing among different

physical networksboth Ethernet-based and others, such

as CAN-based networks.

Ethernet and EtherNet/IPEtherNet/IP in the process industry is definitely a devel-

oping technologyunlike fieldbus, which has enjoyed 20

years of refinement. However, recent developments and

technology breakthroughs are making EtherNet/IP a viable

alternative to fieldbus.

Ethernet IEEE 802.3 can currently support data trans-

missions up to 10 Gbit/sec. Although EtherNet/IP-enabled

devices deployed over the 802.3 standard currently sup-

port only 10/100 Mbit/sec transmission rates over copper

and fiber, traffic through the network can still use the high-

er transmission rates if the network architecture supportsit. And future variants of EtherNet/IP will advance along

with Ethernet to support even higher transmission rates.

One advantage of EtherNet/IP is that it can support

wireless transmission by using industry standard devices.

When deploying EtherNet/IP over wireless, the user must

consider how wireless system deployment creates latency

in the EtherNet/IP message timing. Note that the same

latency problems exist with wireless fieldbus, but without

the advantages of the latest technological developments

from the Ethernet wireless world.

Cabling distances depend on the 802.3 standard; i.e.,

100 meters for device-to-device when deploying over

copper and 2,000 meters when using fiber deployments.

Power over Ethernet (PoE) is available so that power sup-

plies may not be needed in the field. However, productavailability varies by vendor.

Ethernet switches are also available for use in hazard-

ous locations. Some switches use intrinsically safe PoE for

connecting to field instruments in Zones 1 and 2. Unlike

fieldbus, which can handle multiple devices in hazardous

areas, one switch vendor recommends putting only one

device on a single cable, which is becoming less of an

expense as Ethernet switch prices rapidly decline. Again,

product availability varies by vendor.

Typical Ethernet network topology is trunk-star. However,

device manufactures are starting to embed micro Ethernet

switches into their devicesallowing for linear and ring

topologieswhich reduce the need to create star networktopologies. Redundancy can be achieved through the

appropriate switch architecture and in some instances by

adding a communication interface to allow a single fiber or

copper port to be a node on a redundant ring infrastructure.

In other words, it is possible to put multiple instruments

and devices on the same cable and to provide redundancy

when needed (see Figure 2).

Process instrument perspectiveLooking at the EtherNet/IP protocol from the process

instrument perspective, to whom and to what does an

instrument have to report? The primary responsibility is

Figure 2: The photo shows part of a process plant making hypoallergenic baby food using instrumentation, controllers, and industrial

managed switches on a single EtherNet/IP network. Courtesy: Endress+Hauser


6/16


to the automation or host system. Historically, this has

involved the primary process variable. Secondary respon-

sibility is instrument diagnostics, and last is instrument

configuration data.

Each of the users or consumers of the data that the

instrument produces has different tools and mechanisms

to acquire the data. Each has its own unique requirements

for the use of the data. Considering each of these areas

and how EtherNet/IP not only serves their unique require-

ments, but also creates commonality and convergence

in the processwill help us understand how EtherNet/IP

is not only a very capable fieldbus-type network, but also

provides benefits beyond what typical-level fieldbuses

deliver today and in the future.

Process variables:EtherNet/IP communicates process

variables or I/O data back to the host system at a request-

ed packet interval rate (RPI). This RPI is defined by the

user. Typically, RPI is set based on application require-

ments. RPI rates for EtherNet/IP-enabled devices will vary

based on the manufacturer of the device and the applica-

tions they serve.

Typical RPI times for process instruments, such as

Coriolis and electromagnetic flow meters, on EtherNet/

IP networks are from 5 msec to 10 sec. The device will

communicate I/O data to the automation system at the

RPI rate established when the device is configured in the

system. This variability in selection of the RPI data rateenables the user to optimize the flow of I/O data through

the process and optimize the data crunch through the

microprocessors in the data chain without relying on the

actual network bus rate or frame size specifications.

I/O data can also be provided simultaneously to multipleconsumers (processors, devices, etc.) in the architecture.

In addition to the primary process variable, multivariable

devices, such as mass flow meters, can transmit multiple

variables such as flow, volume, and temperature simulta-

neously, similar to traditional fieldbus architectures.

Configuration of what variables will be transmitted in the

I/O data structure is typically determined by the manufac-

turer of the devices. Some manufacturers allow user con-

figuration of the I/O data structure. Device vendors deploy

device profiles that will interface with the automation sys-

tem and define what these variables are.

If profiles are well defined, the process control engineer

has very little work to do to get devices online and com-municating data throughout the system. Typically, just

verifying the actual device, revision of device, RPI, and the

Ethernet address of the device is all that is required to get

a device up and running.

Diagnostic data:Diagnostic data can be a very general

term and is defined by the task that is being performed by

the technician or operator requiring it. From the device per-

spective, the device can provide diagnostic data to the auto-

mation system, operations personnel, maintenance person-

nel, reliability personnel, and IT personnel, to name a few.

Some of this diagnostic data can be included in the I/O

data structure. For example, diagnostic data for a Coriolis

flow meter includes empty pipe detection, sensor drift,sensor error, electronics error, inhomogeneous mixture

error, ambient and process temperature errors, and other

information. Whatever data are considered critical can be

included in the I/O data during configuration.

Devices also need to provide diagnostic data to techni-

cians operating outside the control area and the automa-

tion systems operator interface tools. One example is

an electrical and instrumentation technician using device

configuration software to reference the voltage delta

between the measuring electrodes in an electromagnetic

flow meter. With appropriate software, the technician can

access the necessary data without interfering with pro-

cess control operations.

Devices on EtherNet/IP can also be polled by a condition

monitoring system to determine if there are any diagnostic

messages that need to be sent to maintenance personnel

as an alert. An industrial PC equipped with asset manage-

ment, maintenance, condition monitoring, or HMI/SCADA

software can access all the I/O and diagnostic information

it needs directly from the devices via the Ethernet interface

(see Figure 3). With fieldbus, the same software has to

access the information from the process historian or data-

base in a DCSat considerable extra cost.

Most EtherNet/IP-enabled devices support SNMP. This

enables IT technicians to monitor, troubleshoot, and admin-

ister network devices using standard network management

COVER STORY

Figure 3: With EtherNet/IP, multiple devices can have access to

an instruments process variable and diagnostic data including

PLCs, PACs, DCSs, and HMIs. These devices can also access soft-

ware running on PC workstations including asset management,

ERP, maintenance, diagnostic programs, and historians. Courtesy:

Endress+Hauser/Rockwell Automation


7/16


tools. For example, suppose that IT is monitoring network

traffic using an SNMP-enabled tool. The software tool

reports that an EtherNet/IP device has exceeded its normal-

ized packet transmission rate, and an e-mail alert is createdand sent to a technician. The technician can then use the

internal Web server of the device for troubleshooting.

This leverages the investments a company has made in

its IT support infrastructure, and minimizes the burden on

the process control engineer from having to also be an IT

support engineer.

Fieldbus, on the other hand, requires detailed knowl-

edge of the fieldbus architecture and cannot leverage

a companys IT infrastructure; the burden is still placed

on the process control engineer to be a network expert.

Fieldbus requires specialized training and knowledge, while

EtherNet/IP is instantly familiar to process automation and

other professionals who have worked with Ethernet.EtherNet/IP has two main messag-

ing connections: I/O data and explicit

connections. Explicit connections are

messages that are not scheduled as

with I/O data, but are delivered on

demand. While the device is handling

I/O data requests, it can simultane-

ously handle on-demand requests. The UDP/TCP mecha-

nism in the TCP/IP Ethernet suite simultaneously deploys

the I/O data and messaging data for the CIP library.

These examples demonstrate a few of the various

requirements of device diagnostic data and the varied

locations to which these data are sent. The ability of

Ethernet to allow this simultaneous collection of data from

the devices is a key benefit.

Compared to traditional fieldbuses, EtherNet/IP has

minimal need to create additional configuration code in the

host system. This reduces the footprint of the process con-

figuration on the host. There is no need to have an addi-

tional software configuration package for the network or to

add additional network interfaces, thus reducing hardware

and software costs.

Some of these benefits are derived from the mere use of

Ethernet and cannot be wholly attributed to the EtherNet/

IP protocol. However, implanting these functions often

makes fieldbus installations expensive, cumbersome, dif-

ficult to support, and sometimes unappealing. Deploying

an Ethernet-based protocol is thus useful in overcoming

fieldbus difficulties and objections.

Configuration data: Configuring and documenting a

process device in an automation system can be a very

time intensive task. EtherNet/IP gives users of these

devices several options for configuration and documenta-

tion by giving them different access points and letting them

use different tools to configure and maintain device con-

figurations.

Ethernet 802.3 provides a large data packetup to

1,500 bytesthat opens up a large chunk of data in a

frame, enabling device vendors to serve up more device

attributes than can be communicated over typical field-

bus protocols. This configuration data for a process

device is communicated at the I/O data level to the

automation system.This gives the automation system access to the configu-

ration parameters of a process device, allowing the user

to determine which, if any, configuration parameters can

be accessible to system programmers or operators at the

operator workstations. This provides flexibility during start-

up and commissioning for personnel to monitor or change

parameters while working from within their system configu-

ration programs.

Using EtherNet/IP does not require all users to use the

same set of tools. Most devices on Ethernet have a built-

in Web server that gives users access to device param-

eters. This is useful for the IT technician who may not

have access to, or training for, process control softwareor device configuration software tools.

Because the Ethernet/IP protocol

uses the standard OSI model, other

toolsets become available, and can

coexist and function synchronously

throughout the architecture.

Maintenance personnel also have at

their disposal their own tools, such as asset configuration

software and asset management software, for documen-

tation and change management requirements. All this

software can reach devices throughout the EtherNet/IP

network.

Network optimizationEtherNet/IP provides network access beyond the local

area network (LAN) to a wide area network. I/O data can

now traverse from one network to the other through stan-

dard IT hardware. This gives support personnel access

from virtually anywhere in the world, allowing manufactur-

ers and vendors to support their customers remotely.

It also provides segmentation and optimization of net-

works using tools that IT companies commonly provide

to the marketplace. Traditional fieldbus implementations

constrain data to their physical network; that data must be

accessed through the host or a third-party communication

interface.

The volume of data on the network is increasing as

users begin to merge their business/financial networks

with the plant automation system network. This creates an

ever increasing need to segregate, constrain, and secure

the traffic so that it does not impact the data throughput of

the automation networks. IT suppliers have been provid-

ing the hardware and tools to support these needs, and

that technology is now employed on industrially hardened

Ethernet-based devices.

Some IT vendors are also providing switch diagnostic

data as I/O data in the CIP library. This commercially avail-

able technology allows the engineer to segregate networktraffic inside the common hardware appliances, allowing

Ethernet has been the domi-

nant commercial network for

the past 40 years, and will

continue to be in the future.


8/16


9/16


Improving motion networknoise immunityAutomatic retry can double the noise immunity of real-time industrial

Ethernet-based motion networks.

Most modern motion control systemsemploy Ethernet-based networks to

transmit data among various electrical

and electronic components. The electri-

cal noise immunity of these networks is

critical to operation, as are the methods

employed to deal with interruptions in data transmission

due to electrical noise and other factors.

Designers of real-time motion control systems expect

Ethernet-based motion networks to transport cyclic com-

mand and feedback data at specified intervals with per-

fect data integrity. The designers selection of the motion

control systems gains and trajectories is predicated on

this fundamental assumption.

But in many industrial applications, Ethernet cabling

must be located in the presence of electrical noise caused

by power switchgear, large motors, or other electrically

noisy equipment. If such noise interferes with the net-

work and causes data loss, the designers assumptions

are invalid and the system will not behave as designed.

Problems such as control loop instability and trackingerrors can result, as can other operational issues.

To optimize system performance when real-time

Ethernet networks must be operated in electrically noisy

environments, potential data loss due to noise must be

characterized and accounted for in the system design.

One strategy to reduce data loss is to use a network

protocol that incorporates retry, which is a mechanism for

automatic retransmission of corrupt or missing data within

the same transmission cycle. If retry is built into the net-

work hardware, no explicit action is required by master or

slave to detect errors or trigger data retransmission.

This article quantifies the contribution of retry to

improved noise immunity by testing the noise immu-

nity performance of two real-time industrial Ethernet

protocols and comparing the results. The two real-time

industrial Ethernet protocols

are MECHATROLINK-III, which

includes retry, and network X,

which does not. Although the

trade name of network X isnt

specified in this article, its noise

immunity performance is similar

to other Ethernet-based motion

control networks that dont incor-

porate retry.

Design factorsFactors that influence the noise

immunity of a motion network

include:

The noise immunity of the

By Derek Lee and Ted Phares,Yaskawa America Inc., Drives and Motion Div.

The test/demo stand shown in this

photo is capable of testing up to

32 servo control axes over the

MECHATROLINK-III network. Courtesy:

Yaskawa America Inc.

MOTION CONTROL NETWORKS


10/16


physical layer. Relevant design factors include properties of

the network cabling (shielding), the signaling scheme (sin-

gle-ended vs. differential), and details of the transmit and

receive circuitry (isolation, impedance, filtering, etc.).

The noise immunity of the communication protocol.

Relevant design factors include the protocols error

detection and correction mechanisms.

Most real-time industrial Ethernet protocols use the

same physical layer, specifically 100Base-T Ethernet.

For networks based on similar 100Base-T hardware, the

physical layer is not a differentiating factor for differenc-

es in noise immunity performance. However, because

MECHATROLINK-III and network X nodes are imple-

mented on different application-specific integrated cir-

cuits (ASICs), it was not possible to test both networks

on exactly the same hardware.

In this investigation, differences between the

Ethernet physical layer implementations for the

MECHATROLINK-III and network X networks tested

included:

Different Ethernet connectors and cables

Different Ethernet physical layer circuitry and

printed circuit board layouts

Different Ethernet communication ASICs.

The MECHATROLINK-III protocol includes checksum

and watchdog mechanisms for detection of corrupt

and missing cyclic data, as well as a retry mecha-

nism for automatic retransmission of corrupt or miss-

ing data within the same transmission cycle. When

enabled, retry is a fully automatic feature built into the

MECHATROLINK-III hardware, so no explicit action is

required by master or slave to detect errors or trigger

data retransmission

(see Figure 1).

The network X proto-

col uses checksums to

detect data corruption,

but provides no mecha-

nism for automatic

retransmission or retry

within the same cyclic

update period. If a cyclicdata packet is missing or

is corrupt, the master or

slave must go without its

command or response

data until the next cyclic

data packet arrives successfully.

This lack of retry is a fundamental difference among

real-time industrial Ethernet network protocols. In the

case of MECHATROLINK-III, there are dedicated time

slots for each node, which makes per-node retry feasi-

ble. By contrast, many other Ethernet-based protocols

prioritize data throughput above allocating bandwidth

to a retry mechanism, making the implementation of aretry mechanism infeasible.

Test methods

MECHATROLINK-III and network X motion networks

were set up a in a noise-testing laboratory. A noise simula-

tor was used to inject electrical noise into the motion net-

work cabling while each network was in operation. During

testing, both master and slaves were observed for indica-

tions of data loss on the motion network. The overall goal

of the testing was to determine, for each network configu-

ration, the lowest magnitude noise voltage level (positive

and negative) that caused data loss.

The simulated noise that was used in this investigation

is called impulse noise. This method of generating noise

is commonly used to simulate noise encountered in indus-

trial environments. Associated industrial standards include

Nippon Electric Control Equipment Industries Association

guideline TR-28 and Japan Electrical Manufacturers

Association guideline JEM-TR177.

Each test run consisted of injecting noise for 10 min-

utes, or until data loss was observed. The test configu-

ration for both motion networks consisted of a master

commanding two servo amplifiers (see Figure 2). The

master sent data to the amplifiers at a cyclic update

rate of 4 kHz. Power supply, I/O, and earth ground con-nections for both the master and amplifier hardware

MOTION CONTROL NETWORKS

Transmission cycle TMCYC

Master

Slave

Communicationphases

Synchro-nization

Cyclic communicationRetry of cyclic

communication

C1 mastermessage

communication

C2 mastermessage

communication

C2 message send start timeC2_DLY

SYNC: Synchronous frameCMD #n: Output (command) data to slave #nRSP #n: Input (response) data from slave #nCMD #m: Retry of sending the output (command) data to slave #m

RSP #m: Retry of receiving the input (response) data from slave #mMSG: C1 master message communicationPP: C2 master message communication

SYNCCMD#1

CMD#1

CMD#m

MSG#n

RSP#1

RSP#1

RSP#m

ACK orMSG #n

PP

ACK orPP

RSP#2

RSP#n

CMD#2

CMD#n SYNC

Figure 1: This diagram shows

the data format of the

MECHATROLINK-III transmis-

sion cycle. Courtesy: Yaskawa

America Inc.


11/16


12/16


13/16


able performance, making Web-based thin clients a better

choice than secure viewers, which require their own dedi-

cated network.

Web-based thin clients lower networking costs, as one

of the most expensive components of many SCADA sys-

tems is the communications infrastructure, particularly as

the distance between the control room and the thin client

increases (see Figure 1).

A Web-based thin client enables users to access the

SCADA system via a Web browser from a PC connected

to the Internet. Like the secure viewer, the Web-based thin

client replicates local run time screens, though often not to

the full extent of a secure viewer. It can provide read-only

or read/write access for a complete virtual SCADA experi-

ence. Advantages of Web-based thin clients include:

Exceptional flexibility for remote users

Reduced communication infrastructure costs

No software installation required at thin client

Very easy to use via familiar Web browsers.

When selecting a SCADA software package, its impor-

tant that it provides the ability to create secure viewer and

Web-based thin client applications using the same devel-

opment environment. Requiring developers to create one

configuration for secure viewers, and yet another in HTML

for Web-based thin clients, wastes valuable time. And this

isnt just an issue for development, as it also arises when

implementing updates and patches, which will have to be

done twice as well.

Mobile clientsMobile clients take the Web-based thin client concept to

another level by providing access to the SCADA system

via handheld devices such as smartphones and tablets(see Figure 2). Not only does this promote exceptional

mobility, it can also lower both com-

munications and hardware costs.

Advantages of mobile clients include:User is not tied to a fixed location

Lowest hardware costs

Lower communication costs than

Web-based thin clients

Users can use personal devices

Apps allow quick connection and

two-way access.

Communication costs are lower

because many cell network providers

charge less than Internet providers.

Cell providers are able to provide

inexpensive data access becausethis type of traffic doesnt have the

real-time requirements of voice calls,

making it possible for providers to

use data traffic as a fill-in to wring the

most out of their network capacity.

Hardware costs are lower because smartphones and

tablets are less expensive than PCs and embedded

computing platforms. Some companies are reducing

costs further by implementing bring-your-own-device

policies, which require employees to use their personal

cell phones and tablets for SCADA remote access and

other tasks. In most cases, employees already have

these devices, and companies pay employees a fixed

amount, typically amounting to a portion of their monthly

provider fees.

Access options can be configured to provide users with

read-only access to certain or all tag values and alarm

conditions, or remote control options may be offered.

Remote access to SCADA systems by mobile devices is

typically achieved via a Web browser or an app. There

is a debate over which method provides better access,

but in both cases, screen images must be optimized for

the smaller screens as compared to PCs and embedded

computing platforms.

Incorrectly sized screens for smartphones and small tab-

lets can make remote access unwieldy. Loading graphics

can slow down data retrieval to the point that the applica-

tion times out before the user sees the data, and exces-

sive scrolling is often required to view content designed for

a larger screen. Correctly sizing the screens alleviates this

issue, and a well-designed app can provide further ben-

efits along these and other lines.

Browsers or apps?If remote users are going to be accessing many screens

or graphics, an app is often a better choice than browser-

based access in terms of speed and usability. Apps are

designed specifically for smartphones and other handhelddevices, so screens are generally sized correctly, eliminat-

Figure 1: This diagram of a Web-based client network shows

how thin clients greatly enhance the ability to access SCADA

systems remotely while saving on network costs. Courtesy:

AutomationDirect Inc.


14/16


ing the need for excessive scroll-

ing and long retrieval times.

Many HMI/SCADA software

packages provide a mobile phoneapp for free or for a very nominal

charge. As with thin client and

mobile browser access, remote

users benefit from full-featured

two-way communication. As

compared to a browser, these

SCADA apps connect and load

screens faster to deliver more

rapid response times. While many

of these apps dont require users

to do screen conversions, there is

a small level of effort required for

setup, typically similar to what auser would execute when loading

an app for his or her cell phone.

Whether implementing browser

or app access, its important to

select the right SCADA devel-

opment package. Because the

programming languages used for

Apple products are different from

those used for Android-based and

other tablets and smartphones,

less innovative SCADA suppliers

must write apps and browser-based applications separate-

ly for each operating system type. This means users often

have to wait months for their smartphone or tablet applica-

tion to be developed or upgraded.

However, this problem is easily overcome by choosing

the right SCADA package, specifically from a supplier that

programs its remote access applications in HTML5. This

latest version of HTML works on an open standard that

enables the development of Web applications for multiple

types of devices, including iPhones and Android-based

phones at the same time. A SCADA software package with

HTML5 support will eliminate the development delays for

different types of handheld operating systems.

Improving securitySCADA security is of utmost importance. The general

media has publicized alarming stories on the vulnerability

of SCADA systems, and enabling Internet or cell network

access to SCADA systems does require additional secu-

rity measures such as firewalls, passwords, and possibly

encrypted virtual private networks.

Most SCADA users are familiar with the Stuxnet worm

that was discovered in June 2010. In addition to gain-

ing access to the SCADA system, it was the first major

instance of malware used to destroy equipment. Stuxnet

was an important wake-up call to many companies.

However, many continue to erroneously believe it demon-strates the dangers of the Internet. The Stuxnet worm ini-

tially spread using infected

removable drives (USB

flash drives), and it then

used peer-to-peer remoteprocedure calls to infect

other computers inside pri-

vate networks that werent

connected to the Internet.

This example is used to

show that any network

regardless of how its

accessedis vulnerable to

attacks if its not properly

protected. Its equally impor-

tant to prohibit unauthorized

access from the PCs con-

nected to a private networkas it is to create firewalls for

Web-based and cell network

access. Industrial secu-

rity experts advise treating

SCADA security with an in-

depth strategy that leverag-

es common IT practices and

security measures including

firewalls, encryption, and

proper procedures.

A firewall is a hardware

appliance or software application that monitors network

traffic based on user-defined or preconfigured rules toprevent unauthorized access. There are different types

of firewalls, with some offering enhanced safeguards for

industrial use. Password protection and encryption will

further strengthen the network against intrusion.

Many companies use a virtual private network (VPN)

to secure communications between multiple networks

or multiple hosts. A VPN establishes a protected tun-

nel across the Internet or other communication net-

work that keeps data safe from unauthorized access.

Communications are safeguarded regardless of the

path taken or the distance traveled. Fortunately, todays

advanced SCADA systems offer a high level of protection

and functionality for remote access if implemented cor-

rectly, and if correct security procedures are followed.

Regardless of the device and method used, inevitably

the vast majority of SCADA systems need to provide

some sort of remote access. The very nature of these

systems is to facilitate the monitoring and control of

remote processes and operations, so trying to isolate

the SCADA system creates a real risk of falling behind

competitors. The good news is now SCADA users have

many options for providing that remote access, with dif-

ferent ones to suit each application.

Jeff Payne is the product manager for the Automation

Controls Group at AutomationDirect Inc.

HMI/SCADA

Figure 2: Smartphones, tablets, and other handheld devices

offer remote access from virtually any location, empower-

ing the mobile worker. Courtesy: AutomationDirect Inc.


15/16

Stuck on a Bus?

The investment you have in your fieldbus

system is huge. But, dont feel like you are

stuck with just one supplier. Gateways and

fieldbus cards from SEW-EURODRIVE not

only speak your language, they substantially

increase the performance of your main

PLC by reducing its load. And, best of all

NO more programming! Simply enter your

parameters and go. Startup couldnt be

faster. So, stay on your bus and leave the

driving to us.

seweurodrive.com / 864-439-7537


16/16

Answers for industry.

Intuitive, efficient, proven: Totally

Integrated Automation Portal (TIA

Portal) redefines engineering.

Your plus of efficiency:

+ Innovative design and easy handling

for simple usage and commissioning

as well as safe operation+ Integrated system diagnosis

for full transparency of the plant

status, automatically generated

and consistently displayed

+ TIA Portal for highest engineering

efficiency and reduced project cost

Experience the new controllers

highlights online: siemens.com/s7-1500-aa

Highest performance highest usability:

SIMATIC S7-1500 is the new generation

of controllers in the TIA Portal and a

milestone in automation.

Your plus of power:

+ Outstanding system performance

for shortest response times and

highest quality of control

+ Technology Integrated for perfect

integration of drives through motion

control functionalities and PROFIdrive

+ Security Integrated consistently

incorporated for highest investment

protection

www.usa.siemens.com/s7-1500-aa

SIMATIC S7-1500 plus TIA PortalThe ultimate plus in automation

2013SiemensIndustry,

Inc.

Want

trial

software?

f628ba4380896c1fbc0cb3e329f33ec7a7bdb51b.1

Documents