A supplement to PLANT

ControlENGINEERING
Engineering
and Control Engineering magazines
PLANT ENGINEERING magazines
 C-more around your plant!
®

Practical, Powerful and Priced Right

6” TFT Touch Panel
starting at:

$
540.00 u.s.
EA7-T6CL-R ( w/serial port )
C-more operator
touch panels offer:
• Clear TFT 65K color displays with
6 to 15-inch screens (6-inch STN models
also available)
• Analog touch screen for maximum flexibility
• Easy-to-use software

Our C-more remote HMI application,

for iPad®, iPhone® or iPod touch®, is
available on the App Store for $4.99.
It provides remote access and control
to a C-more panel for mobile users
who have a wi-fi or cellular connection.

CONNECT TO CONTROLLERS WITH DRIVERS FOR:

C-more touch panels in 6” to 15” screen sizes are a practical • All AutomationDirect programmable controllers
way to give plant personnel easy access to controls and data. • Allen-Bradley - ControlLogix®, CompactLogix®,
Check out the powerful yet easy-to-use configuration software MicroLogix™ Ethernet, SLC Series, FlexLogix,
by downloading a demo version at: SLC® 5/05 Ethernet™
• Modbus RTU and TCP/IP Ethernet
http://support.automationdirect.com/demos.html
• GE SNPX
• Omron Host Link Adapter (C200/C500), FINS Serial
ALL C-MORE PANELS INCLUDE: and Ethernet
• Analog resistive touch screen with unlimited touch areas • Selected Mitsubishi FX Series, Q Series
• One USB A-type and one USB B-type port • Siemens S7-200 PPI and S7-200/300 Ethernet
• Serial communications interface (ISO over TCP/IP)

FULL-FEATURED MODELS ADD: Research, price, buy at:

• 10/100Base-T Ethernet communications www.automationdirect.com/c-more
• CompactFlash slot for data logging
REMOTE ACCESS AND CONTROL BUILT-IN C-more touch panel family: 15-inch TFT
12-inch TFT
• No Additional Hardware required. The C-more 6-inch STN 6-inch TFT 8-inch TFT
10-inch TFT

Remote Access feature resides in all panels with grayscale 65,538 colors

Ethernet support, and requires no option modules.

Access real-time data or initiate an action on a
control system from anywhere, any time. Starting at: Starting at: $1,081 $1,727 $2,051 $2,484
(Requires software and firmware version 2.4 $432 (serial) $540 (serial)
$540 (adds Ethernet) $757 (adds Ethernet) 8 to 15-inch units include both serial and Ethernet ports
or later*, and an Ethernet C-more panel)

Order Today, Ships Today!

* See our Web site for details and restrictions. © Copyright 2013 AutomationDirect, Cumming, GA USA. All rights reserved.
1-800-633-0405 the #1 value in automation
Contents
A4 Using EtherNet/IP in process
automation instead of fieldbus
EtherNet/IP takes advantage of Ethernet commercial
technologies to surpass alternative solutions.
A9 Improving motion network
noise immunity
Automatic retry can double the noise immunity of real-time
industrial Ethernet-based motion networks.
A12 Selecting the right SCADA
technology
Modern SCADA technologies offer choices that satisfy
functionality and security requirements while improving
performance for remote users.
C OMME NT
The evolving Ethernet
E
thernet has come a long way since the
days of 10BASE5 and 10BASE2. While
editing the cover story for this issue, I
couldn’t 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
Jack Smith involved keeping the network up. More than a
Edit or 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
A4
On the cover
This photo shows part of a process plant making
hypoallergenic baby food using instrumentation, con-
trollers, and industrial managed switches on a single
EtherNet/IP network. Courtesy: Endress+Hauser
A9
BNC T-connectors; they weren’t allowed with
10BASE5. Also, the maximum number of
10BASE2 nodes was limited to 30. And this was
a multidrop trunk—no 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.
Applied Automation October 2013 • A3
 COVER STORY

Using EtherNet/IP in process

automation instead of fieldbus
EtherNet/IP takes advantage of Ethernet commercial technologies
to surpass alternative solutions.

By Michael Robinson, EtherNet/IP:

En d res s +Hau s e r n Is easier to connect to a variety

S
of host systems
n Can communicate with multiple
ince its invention in 1973, hosts simultaneously
Ethernet has changed n Is instantly familiar to anyone
the world. It will continue with Ethernet experience
to deliver the fastest data n Can use all available Ethernet
throughput, improve the tools and technologies
architectures upon which n Can use quality of service
it is delivered, evolve into varying (QoS) to prioritize network traffic
electromechanical spectrums to meet n Can use simple network man-
the next industry trend, and penetrate agement protocol (SNMP) to
down into the tiniest of microproces- monitor and manage the network
Figure 1: Process instrumentation with
sors. Our world of process and fac- n Has more network topology
tory automation is no exception to the EtherNet/IP connections, such as the options when switches are
ever-reaching technological advance- Coriolis flow meter shown in the photo, is deployed
ments of this network. becoming more common as users realize n Provides better support for wireless
Around 20 years ago, the process the benefits. Courtesy: Endress+Hauser data transmission
automation market had proprietary n Provides better security through the
ways to meet the demands of remote I/O peer-to-peer use of standard Ethernet tools
communications. These approaches were successful and n Offers economies of scale that promise future gains
supportable, but users began to demand that their automa- that are outpacing fieldbus.
tion systems interface and share more data automatically
with their front office systems over Ethernet. This article explores these benefits.
Automation vendors began connecting their control sys-
tems via Ethernet, but there was no workable way to deploy Industrial Ethernet protocols
device control requirements over a non-deterministic net- Within the Ethernet frame, one can place almost any
work infrastructure like Ethernet. As process users started application protocol. There is no one particular protocol
to transition from traditional 4-20 mA analog devices and that serves all the needs of industry. Instead, application
demanded digital device communications, fieldbus networks protocols are like a tool chest, with users picking the ones
emerged to meet the demands that Ethernet couldn’t. that support the demands of their particular automation
Today, Ethernet communication has overcome many of applications to provide the required performance, security,
the disadvantages of previous years and established its and safety.
presence in field device communications. The focus for this article is on EtherNet/IP, the indus-
In factory automation, Ethernet-based networks are trial Ethernet protocol supported by the Open Device
being used to connect robots, variable speed drives, and Vendor Association (ODVA). EtherNet/IP uses the stan-
actuators to automation controllers. In the process control dard Ethernet frame as defined by IEEE 802.3 and uses
world, EtherNet/IP now connects flow meters, pressure ODVA’s and ControlNet International’s Common Industrial
instrumentation, and similar field devices to distributed Protocol (CIP) application protocol library of objects.
control systems, programmable controllers, and hybrid The CIP application library can be deployed upon sever-
programmable automation controllers (see Figure 1). al different physical network architectures. This is a unique
While there is no network panacea, EtherNet/IP has benefit to users because there are no physical application
benefits that some fieldbus architectures cannot deliver. interfaces between the layers. This gives the CIP library

A4 • October 2013 Applied Automation

almost seamless bridging and routing among different
physical networks—both Ethernet-based and others, such
as CAN-based networks.
Ethernet and EtherNet/IP
EtherNet/IP in the process industry is definitely a devel-
oping technology—unlike 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 supports
it. 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
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
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, product
availability 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 devices—allowing for linear and ring
topologies—which reduce the need to create star network
topologies. 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 perspective
Looking 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
Applied Automation October 2013 • A5
 COVER STORY
Figure 3: With EtherNet/IP, multiple devices can have access to
an instrument’s 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
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 process—will 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 rate
enables the user to optimize the flow of I/O data through
A6 • October 2013 Applied Automation
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 multiple
consumers (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 system’s 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 DCS—at 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
tools. For example, suppose that IT is monitoring network attributes than can be communicated over typical field-
traffic using an SNMP-enabled tool. The software tool bus protocols. This configuration data for a process
reports that an EtherNet/IP device has exceeded its normal- device is communicated at the I/O data level to the
ized packet transmission rate, and an e-mail alert is created automation system.
and sent to a technician. The technician can then use the This gives the automation system access to the configu-
internal Web server of the device for troubleshooting. ration parameters of a process device, allowing the user
This leverages the investments a company has made in to determine which, if any, configuration parameters can
its IT support infrastructure, and minimizes the burden on be accessible to system programmers or operators at the
the process control engineer from having to also be an IT operator workstations. This provides flexibility during start-
support engineer. up and commissioning for personnel to monitor or change
Fieldbus, on the other hand, requires detailed knowl- parameters while working from within their system configu-
edge of the fieldbus architecture and cannot leverage ration programs.
a company’s IT infrastructure; the burden is still placed Using EtherNet/IP does not require all users to use the
on the process control engineer to be a network expert. same set of tools. Most devices on Ethernet have a built-
Fieldbus requires specialized training and knowledge, while in Web server that gives users access to device param-
EtherNet/IP is instantly familiar to process automation and eters. This is useful for the IT technician who may not
other professionals who have worked with Ethernet. have access to, or training for, process control software
EtherNet/IP has two main messag- or device configuration software tools.
ing connections: I/O data and explicit Ethernet has been the domi- Because the Ethernet/IP protocol
connections. Explicit connections are nant commercial network for uses the standard OSI model, other
messages that are not scheduled as toolsets become available, and can
with I/O data, but are delivered on the past 40 years, and will coexist and function synchronously
demand. While the device is handling throughout the architecture.
continue to be in the future.
I/O data requests, it can simultane- Maintenance personnel also have at
ously handle on-demand requests. The UDP/TCP mecha- their disposal their own tools, such as asset configuration
nism in the TCP/IP Ethernet suite simultaneously deploys software and asset management software, for documen-
the I/O data and messaging data for the CIP library. tation and change management requirements. All this
These examples demonstrate a few of the various software can reach devices throughout the EtherNet/IP
requirements of device diagnostic data and the varied network.
locations to which these data are sent. The ability of
Ethernet to allow this simultaneous collection of data from Network optimization
the devices is a key benefit. EtherNet/IP provides network access beyond the local
Compared to traditional fieldbuses, EtherNet/IP has area network (LAN) to a wide area network. I/O data can
minimal need to create additional configuration code in the now traverse from one network to the other through stan-
host system. This reduces the footprint of the process con- dard IT hardware. This gives support personnel access
figuration on the host. There is no need to have an addi- from virtually anywhere in the world, allowing manufactur-
tional software configuration package for the network or to ers and vendors to support their customers remotely.
add additional network interfaces, thus reducing hardware It also provides segmentation and optimization of net-
and software costs. works using tools that IT companies commonly provide
Some of these benefits are derived from the mere use of to the marketplace. Traditional fieldbus implementations
Ethernet and cannot be wholly attributed to the EtherNet/ constrain data to their physical network; that data must be
IP protocol. However, implanting these functions often accessed through the host or a third-party communication
makes fieldbus installations expensive, cumbersome, dif- interface.
ficult to support, and sometimes unappealing. Deploying The volume of data on the network is increasing as
an Ethernet-based protocol is thus useful in overcoming users begin to merge their business/financial networks
fieldbus difficulties and objections. with the plant automation system network. This creates an
Configuration data: Configuring and documenting a ever increasing need to segregate, constrain, and secure
process device in an automation system can be a very the traffic so that it does not impact the data throughput of
time intensive task. EtherNet/IP gives users of these the automation networks. IT suppliers have been provid-
devices several options for configuration and documenta- ing the hardware and tools to support these needs, and
tion by giving them different access points and letting them that technology is now employed on industrially hardened
use different tools to configure and maintain device con- Ethernet-based devices.
figurations. Some IT vendors are also providing switch diagnostic
Ethernet 802.3 provides a large data packet—up to data as I/O data in the CIP library. This commercially avail-
1,500 bytes—that opens up a large chunk of data in a able technology allows the engineer to segregate network
frame, enabling device vendors to serve up more device traffic inside the common hardware appliances, allowing

Applied Automation October 2013 • A7

 COVER STORY

for even faster propagation of critical
data inside the network topology.
There will be some applications
where a user may not be able to
completely segregate or constrain
the data to a virtual LAN or local sub-
net. The issue now becomes being
able to compete for the data pack-
ets to be processed in the switches
throughout the network. EtherNet/
IP has identifiers in the CIP library to
allow a switch, configured for QoS,
to prioritize these packets over the
voice, data, and media packets on the
network. Being able to perform these
QoS tasks within the network provides
the best optimization of the network
for the automation network data.
Security is a wide and deep topic
and is not addressed in this article,
other than to note that EtherNet/IP
is able to leverage all of the com-
mercially available security features
that are delivered in the IT market
today for Ethernet-based networks.
There are several publicly available
documents for securing converged
networks, and the ODVA website has
a publication that discusses securing
Ethernet networks.

Looking ahead
Ethernet has been the dominant
commercial network for the past
40 years, and will continue to be
in the future. As the convergence
of the plant floor to the front office
continues its progress, leveraging
this future in automation devices will
be essential. Process devices will

Fast EtherNet/IP
get more intelligent—the past and
present demonstrate this. A process

connections
device will have a lot of information
to share, and will need ever more
network capacity and capabilities.
EtherNet/IP will meet these needs
by leveraging Ethernet advances,
taking advantage of Ethernet’s huge
economies of scale. More Ethernet
nodes will be connected this—or any
other—month than have been con-
nected in the entire history of field-
bus. This economy of scale and the
tremendous technological advance-
ments that go along with it is what
ascii • modbus • modbus tcp
to
makes EtherNet/IP more capable
than a fieldbus network, now and
or siemens industrial etherne t especially in the future.

Our PLX30 gateways feature real-time Michael Robinson is director of

data transfers and multiple I/O connections. solutions for the Endress+Hauser
Sales Center, US. He has 18 years
of experience in factory and process
automation as a project engineer,
product manager, and business
development manager. Robinson
has a BS in agricultural engineer-
ing technology from California
Where Automation Connects Polytechnic State University, San
+1-661-716-5100 Luis Obispo, Calif.
www.prosoft-technology.com/PLX30
A S I A PA C I F I C | A F R I C A | E U R O P E | M I D D L E E A S T | L AT I N A M E R I C A | N O R T H A M E R I C A A8 • October 2013 Applied Automation
 Motio n control networks
Improving motion network
noise immunity
Automatic retry can double the noise immunity of real-time industrial
Ethernet-based motion networks.
By Derek Lee and Ted Phares,
Yask awa America Inc., D ri ve s a n d M ot i on D i v.
M
ost modern motion control systems
employ 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 designer’s selection of the motion
control system’s 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 designer’s assumptions
are invalid and the system will not behave as designed.
Problems such as control loop instability and tracking
errors 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 isn’t
specified in this article, its noise
immunity performance is similar
to other Ethernet-based motion
control networks that don’t incor-
porate retry.
Design factors
Factors that influence the noise
immunity of a motion network
include:
n The noise immunity of the
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.
Applied Automation October 2013 • A9
 Motio n control networks

Figure 1: This diagram shows

Transmission cycle TMCYC the data format of the
MECHATROLINK-III transmis-
C2 message send start time sion cycle. Courtesy: Yaskawa
C2_DLY
America Inc.
Master
CMD CMD CMD CMD CMD MSG
SYNC #1 #2 #n #1 #m #n PP SYNC data retransmission
RSP RSP RSP RSP RSP ACK or ACK or (see Figure 1).
#1 #2 #n #1 #m MSG #n PP The network X proto-
Slave col uses checksums to
detect data corruption,
but provides no mecha-
Communication Synchro- Retry of cyclic C1 master C2 master nism for automatic
phases nization Cyclic communication communication message message retransmission or retry
communication communication
within the same cyclic
update period. If a cyclic
SYNC: Synchronous frame RSP #m: Retry of receiving the input (response) data from slave #m data packet is missing or
CMD #n: Output (command) data to slave #n MSG: C1 master message communication is corrupt, the master or
RSP #n: Input (response) data from slave #n PP: C2 master message communication
CMD #m: Retry of sending the output (command) data to slave #m slave must go without its
command or response
data until the next cyclic
physical layer. Relevant design factors include properties of data packet arrives successfully.
the network cabling (shielding), the signaling scheme (sin- This lack of retry is a fundamental difference among
gle-ended vs. differential), and details of the transmit and real-time industrial Ethernet network protocols. In the
receive circuitry (isolation, impedance, filtering, etc.). case of MECHATROLINK-III, there are dedicated time
n The noise immunity of the communication protocol. slots for each node, which makes per-node retry feasi-
Relevant design factors include the protocol’s error ble. By contrast, many other Ethernet-based protocols
detection and correction mechanisms. prioritize data throughput above allocating bandwidth
to a retry mechanism, making the implementation of a
Most real-time industrial Ethernet protocols use the retry mechanism infeasible.
same physical layer, specifically 100Base-T Ethernet.
For networks based on similar 100Base-T hardware, the Test methods
physical layer is not a differentiating factor for differenc- MECHATROLINK-III and network X motion networks
es in noise immunity performance. However, because were set up a in a noise-testing laboratory. A noise simula-
MECHATROLINK-III and network X nodes are imple- tor was used to inject electrical noise into the motion net-
mented on different application-specific integrated cir- work cabling while each network was in operation. During
cuits (ASICs), it was not possible to test both networks testing, both master and slaves were observed for indica-
on exactly the same hardware. tions of data loss on the motion network. The overall goal
In this investigation, differences between the of the testing was to determine, for each network configu-
Ethernet physical layer implementations for the ration, the lowest magnitude noise voltage level (positive
MECHATROLINK-III and network X networks tested and negative) that caused data loss.
included: The simulated noise that was used in this investigation
n Different Ethernet connectors and cables is called impulse noise. This method of generating noise
n Different Ethernet physical layer circuitry and is commonly used to simulate noise encountered in indus-
printed circuit board layouts trial environments. Associated industrial standards include
n Different Ethernet communication ASICs. Nippon Electric Control Equipment Industries Association
guideline TR-28 and Japan Electrical Manufacturers’
The MECHATROLINK-III protocol includes checksum Association guideline JEM-TR177.
and watchdog mechanisms for detection of corrupt Each test run consisted of injecting noise for 10 min-
and missing cyclic data, as well as a retry mecha- utes, or until data loss was observed. The test configu-
nism for automatic retransmission of corrupt or miss- ration for both motion networks consisted of a master
ing data within the same transmission cycle. When commanding two servo amplifiers (see Figure 2). The
enabled, retry is a fully automatic feature built into the master sent data to the amplifiers at a cyclic update
MECHATROLINK-III hardware, so no explicit action is rate of 4 kHz. Power supply, I/O, and earth ground con-
required by master or slave to detect errors or trigger nections for both the master and amplifier hardware

A10 • October 2013 Applied Automation

were made according to the manufacturer’s installation
instructions. Accessory noise filtering devices, such
as ferrite cores, were not used on the motion network
cabling.
Different configurations of the MECHATROLINK-III mas-
ter were tested. In the first configuration, retry was dis-
abled. In this configuration, lost cyclic data packets are not
resent. In the second configuration, retry was enabled. In
that configuration, the master triggers the resending of up
to one lost cyclic data packet per transmission cycle.
n Master:
1. Cyclic redundancy check error counters (count of
incidences of data corruption on the network)
2. Lost frame counters (count of lost Ethernet data frames)
n Transmit/receive error counters (count of errors when
communicating with the PC Ethernet adapter).
n Slave:
1. Drive alarms or warnings related to missing or
unexpected data
2. Interrupted motion.

Test criteria Note that, unlike the MECHATROLINK-III network that

The motion network master and slaves were was tested, the designer must take explicit steps to moni-
observed for signs of data loss during each test run. For tor error counters on network X. Otherwise, undetected
MECHATROLINK-III, the following indicators of lost data data loss may occur.
were checked:
n Master: Results and conclusions
1. Controller alarms or warnings related to lost or The MECHATROLINK-III network was tested with retry
unexpected MECHATROLINK data. disabled, and with retry enabled, which is the normal set-
n Slave: ting. Data loss with retry disabled occurred at -2,500 V
1. Drive alarms or warnings related to missing or and +2,000 V. With retry enabled, data loss occurred at
unexpected MECHATROLINK data -3,000 V and +3,000 V. This indicates that retry improved
2. Interrupted motion. MECHATROLINK-III noise immunity by up to 1,000 V.
By default, the MECHATROLINK-III slaves that were
Because the MECHATROLINK-III master and slaves tested generate alarms if data loss occurs that cannot be
that were tested are designed to raise an alarm when- corrected by the retry mechanism. In the absence of these
ever loss of cyclic data is detected, drive and control- alarms, the application engineer is assured that data loss
ler alarms are sufficient indications of data loss on the has not occurred.
motion network. Network X data loss was observed at -2,000 V and
For network X, the following indicators of lost data +1,500 V. The Network X slaves that were tested did not,
were checked: by default, generate alarms in the case of data loss. For
slaves such as these, the application engineer must either
change configuration parameters or implement controller
Motion software to monitor internal counters to determine if data
network loss has occurred.
master Power supply Therefore, the MECHATROLINK-III network implementa-
5 meter motion tion that was tested in this investigation, when configured
network cable
Main to use retry, had twice the noise amplitude range with no
Noise Noise power data loss compared to network X.
simulator coupler supply Ethernet-based motion control networks designed to
50 cm Control incorporate retry have significantly better performance
separation power when transmitting data in the types of electrically noisy
Servo supply environment typically found in industrial plants and facili-
amplifier 1
ties. This superior performance is delivered at a price point
similar to networks that don’t incorporate a retry feature.
0.5 meter motion Motor
network cable
Derek Lee is a motion product engineer with Yaskawa
Servo
amplifier 2 America Inc., and has held this position for 8 years.
He is based at Yaskawa’s headquarters in Waukegan,
Ill., and is a representative of the U.S. branch of the
Motor
MECHATROLINK Members Association.

Ted Phares is an embedded systems development man-

Figure 2: This diagram shows the test configuration for both ager and has been with Yaskawa America Inc. for the last 6
motion networks, which consisted of a master commanding two years. He is based at Yaskawa’s development office in San
servo amplifiers. Courtesy: Yaskawa America Inc. Francisco and has 15 years of experience in the industry.

Applied Automation October 2013 • A11

 HMI/SCADA
Selecting the right
SCADA technology
Modern SCADA technologies offer choices that satisfy functionality and
security requirements while improving performance for remote users.
By Jeff Payne, Aut oma t i on D i re c t In c .
W
hen supervisory control and data
acquisition (SCADA) systems were
first developed and deployed on main-
frame and mini computers, access
was limited to local displays and to
data terminals, which were typically
located in close proximity to the main computing platform.
Networking was proprietary and limited to connections to
the data terminals, with no concept of open systems or
remote access.
Much has changed since those early days, as SCADA
and automation systems are now usually connected to an
extensive and open communications network within a plant
or facility. With fewer staff tasked with more responsibili-
ties, it’s often necessary to extend the SCADA system
to remote users—either through the plant network or via
other means.
Modern, networked SCADA systems offer many advan-
tages over their predecessors, most notably in terms of the
functionality, speed, and low cost of remote access. They
are designed to provide easy data collection and control
for remote sites, and extensive options for remote access
to perform monitoring and control. Web-based SCADA has
taken this paradigm to the next level as it supplies users—
regardless of their location—with similar access to what
they would have in the control room.
Modern SCADA systems provide local control and moni-
toring along with global access, giving workers crucial infor-
mation when and where they need it. They include valuable
tools, such as configurable alarms, that help personnel
prevent small issues from escalating into major problems. In
addition, these advanced solutions deliver powerful visual-
ization capabilities to help identify the root cause of alarms.
SCADA systems also offer impressive trending and report-
ing capabilities to improve overall operations and maintain
compliance with government regulations.
There are three main methods for accessing SCADA
systems remotely: secure viewer thin clients, Web-based
thin clients, and mobile clients. This article provides an
overview of these methods, and also examines the best
option for different applications.
A12 • October 2013 Applied Automation
Secure viewer thin clients
A secure viewer replicates the local SCADA run time
screens on a thin client, typically a PC or a less powerful
embedded computing device. When a PC is used, it often
is used for multiple functions in addition to SCADA remote
access. When an embedded computing device is used, it
functions as a dedicated remote access terminal.
Many consider this the most secure method for remote
viewing because the thin clients are connected to the
server via a secure corporate network, typically with no
Internet connectivity allowed. Thin client screen naviga-
tion and interaction can also be restricted to specific HMI/
SCADA functions to further safeguard the system. For
example, a particular user could be assigned a password
commensurate with his or her access requirements, with
more extensive access prohibited.
While this solution can’t be accessed over the Internet,
it is compatible with both wired and wireless networks.
In addition, it offers encryption capabilities using secure
socket layer (SSL-RC6 Standard) 128-bit encryption tech-
nology to provide a high level of security.
As well as being highly secure, this solution is also very
easy to deploy, as it simply requires the installation of
secure viewer software to permit users to interact with the
graphical interface of the SCADA system. Users view the
screens on the client as if they were in front of the main
terminal, and they can be granted read-only or read/write
privileges. Advantages of secure viewer thin clients include:
n Most closely replicates local viewing experience
n Highest speed
n Very high security as Internet access can be
prohibited
n Wired or wireless networking capabilities.
Some SCADA packages allow all of the software, appli-
cations, and licenses to be stored on the local server. This
simplifies implementation by reducing, or even eliminating,
the need to install software on the secure viewers. It also
facilitates the deployment of applications that require mul-
tiple, simultaneous views across multiple screens.
Web-based thin clients
For remote access far from the control room, the
Internet often provides low-cost networking with accept-
 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.
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:
n Exceptional flexibility for remote users
n Reduced communication infrastructure costs
n No software installation required at thin client
n Very easy to use via familiar Web browsers.
When selecting a SCADA software package, it’s 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
isn’t just an issue for development, as it also arises when
implementing updates and patches, which will have to be
done twice as well.
Mobile clients
Mobile 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:
n User is not tied to a fixed location
n Lowest hardware costs
n Lower communication costs than
Web-based thin clients
n Users can use personal devices
n 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 because
this type of traffic doesn’t 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 handheld
devices, so screens are generally sized correctly, eliminat-
Applied Automation October 2013 • A13
 HMI/SCADA

ing the need for excessive scroll- tially spread using infected
ing and long retrieval times. removable drives (USB
Many HMI/SCADA software flash drives), and it then
packages provide a mobile phone used peer-to-peer remote
app for free or for a very nominal procedure calls to infect
charge. As with thin client and other computers inside pri-
mobile browser access, remote vate networks that weren’t
users benefit from full-featured connected to the Internet.
two-way communication. As This example is used to
compared to a browser, these show that any network—
SCADA apps connect and load regardless of how it’s
screens faster to deliver more accessed—is vulnerable to
rapid response times. While many attacks if it’s not properly
of these apps don’t require users protected. It’s equally impor-
to do screen conversions, there is tant to prohibit unauthorized
a small level of effort required for access from the PCs con-
setup, typically similar to what a nected to a private network
user would execute when loading as it is to create firewalls for
an app for his or her cell phone. Web-based and cell network
Whether implementing browser access. Industrial secu-
or app access, it’s important to rity experts advise treating
select the right SCADA devel- SCADA security with an in-
opment package. Because the depth strategy that leverag-
programming languages used for es common IT practices and
Figure 2: Smartphones, tablets, and other handheld devices
Apple products are different from security measures including
those used for Android-based and offer remote access from virtually any location, empower- firewalls, encryption, and
other tablets and smartphones, ing the mobile worker. Courtesy: AutomationDirect Inc. proper procedures.
less innovative SCADA suppliers A firewall is a hardware
must write apps and browser-based applications separate- appliance or software application that monitors network
ly for each operating system type. This means users often traffic based on user-defined or preconfigured rules to
have to wait months for their smartphone or tablet applica- prevent unauthorized access. There are different types
tion to be developed or upgraded. of firewalls, with some offering enhanced safeguards for
However, this problem is easily overcome by choosing industrial use. Password protection and encryption will
the right SCADA package, specifically from a supplier that further strengthen the network against intrusion.
programs its remote access applications in HTML5. This Many companies use a virtual private network (VPN)
latest version of HTML works on an open standard that to secure communications between multiple networks
enables the development of Web applications for multiple or multiple hosts. A VPN establishes a protected tun-
types of devices, including iPhones and Android-based nel across the Internet or other communication net-
phones at the same time. A SCADA software package with work that keeps data safe from unauthorized access.
HTML5 support will eliminate the development delays for Communications are safeguarded regardless of the
different types of handheld operating systems. path taken or the distance traveled. Fortunately, today’s
advanced SCADA systems offer a high level of protection
Improving security and functionality for remote access if implemented cor-
SCADA security is of utmost importance. The general rectly, and if correct security procedures are followed.
media has publicized alarming stories on the vulnerability Regardless of the device and method used, inevitably
of SCADA systems, and enabling Internet or cell network the vast majority of SCADA systems need to provide
access to SCADA systems does require additional secu- some sort of remote access. The very nature of these
rity measures such as firewalls, passwords, and possibly systems is to facilitate the monitoring and control of
encrypted virtual private networks. remote processes and operations, so trying to isolate
Most SCADA users are familiar with the Stuxnet worm the SCADA system creates a real risk of falling behind
that was discovered in June 2010. In addition to gain- competitors. The good news is now SCADA users have
ing access to the SCADA system, it was the first major many options for providing that remote access, with dif-
instance of malware used to destroy equipment. Stuxnet ferent ones to suit each application.
was an important wake-up call to many companies.
However, many continue to erroneously believe it demon- Jeff Payne is the product manager for the Automation
strates the dangers of the Internet. The Stuxnet worm ini- Controls Group at AutomationDirect Inc.

A14 • October 2013 Applied Automation

 Stuck on a Bus?
The investment you have in your fieldbus
system is huge. But, don’t 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 couldn’t be
faster. So, stay on your bus and leave the
driving to us.

seweurodrive.com / 864-439-7537

SIMATIC S7-1500 plus TIA Portal
The ultimate plus in automation
www.usa.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
©2013 Siemens Industry, Inc.
Want
trial
software?
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 Intuitive, efficient, proven: Totally
Integrated Automation Portal (TIA
+ TIA Portal for highest engineering Portal) redefines engineering.
efficiency and reduced project cost
Experience the new controller’s
highlights online: siemens.com/s7-1500-aa
Answers for industry.