A supplement to PLANT

ControlENGINEERING
Engineering
and Control Engineering magazines
PLANT ENGINEERING magazines
 Get the PRO in
COMMUNICATIONS
Other
Controllers

Drives

Universal
I/O

CHECK OUT OUR PRICES

We make it easier to communicate Example
System
AutomationDirect
Productivity3000
Allen-Bradley
CompactLogix
Allen-Bradley
ControlLogix
Now with EtherNet/IP™ as a native protocol, we make it easier Base (if required) $160.50 N/A $560.00
to connect the powerful, cost-effective Productivity3000 P3-08B N/A 1756-A10

controller to your existing systems. 110VAC

power supply
$133.00 $406.50 $1,023.00
P3-01AC 1769-PA4 1756-PA75
Configurable as a Scanner, Adapter, or both simultaneously,
the P3-550 CPU supports Explicit or Implicit “I/O” messaging. CPU $599.00 $5,928.00 $11,917.00
P3-550 1768-L45 1756-L74

Connect to EtherNet/IP enabled devices such as ControlLogix

16pt AC IN $121.00 $282.50 $421.50
and CompactLogix controllers or Flex drives using the P3-16NA 1769-IA16 1756-IA16

Productivity3000’s fill-in-the-blank style configuration and $116.00 $240.50 $343.50

16pt 24 VDC IN
Message instructions. P3-16ND3 1769-IQ16 1756-IB16

Whether you are configuring a new application or looking to 32pt 24 VDC IN $158.00 $423.00 $432.50
expand an existing one, we can get you in control and P3-32ND3 1769-IQ32 1756-IB32

connected for less. 32pt 24 VDC OUT $158.00 $462.00 $611.00

P3-32TD2 1769-OB32 1756-0B32

8pt Isolated $96.00 $263.00 $427.50

Performance Relay OUT P3-08TRS 1769-OW8I 1756-0X8I

+ Value 16 ch 0-20mA
Analog IN
$309.50
P3-16AD-1
$1,056.00
1769-IF16C
$1,413.00
1756-IF16

4 ch volt/mA $249.00 $678.50 $1,092.00

= Analog OUT P3-04DA 1769-OF4 1756-0F4

8 ch THM & mV IN
1
$433.50 $915.50 $2,519.00
www.productivity3000.com
P3-08THM 1769-IT6 1756-IT6I

Total System
Price $2,533.50 $10,655.50 $20,760.00

Thermocouple module from AB is 6-Ch vs. Productivity3000 8-Ch.

1

Research, price, buy at: All prices are U.S. published prices. AutomationDirect prices are from October 2014 Price List. Allen-Bradley prices taken from www.plccenter.com 9/10/2014.

www.automationdirect.com/productivity3000

Order Today, Ships Today!

* See our Web site for details and restrictions. © Copyright 2014 AutomationDirect, Cumming, GA USA. All rights reserved.
All trademarks are the property of their respective owners.
1-800-633-0405 the #1 value in automation
Contents
A4 Electrical power measurement
on 3-phase motors
Testing drive-and-motor systems is a three-step process.

A8 Designing real-time process

controllers
The most important constraint in a real-time system is that the time A4
it takes to process an input and produce an output must be well
known.

A13 Migrating toward enterprise

information systems
Maturity model advice helps organizations move from Level 0,
paper-based systems and homegrown systems, to Level 1,
focused data systems. Maturity models applied to processes
and software help increase decision efficiency, because greater
decision efficiency = lower costs = higher profits. A13

C OMMENT
Exploring measurement, design, and maturity

T
he cover story in this issue of
AppliedAutomation completes the three-
part series on motor measurement from
Yokogawa’s Bill Gatheridge. In this
article, Gatheridge continues his explana-
tion of how to make power measurements
for 3-phase ac motors and drive systems. He
explains why it is important to accurately mea-
Jack Smith sure VFD input and output power, electrical
Editor input power to the motor, and motor mechani-
cal power. He also discusses the use of fil-
ters when measuring PWM VFDs and during
harmonic analysis, as well as how they affect
measurement outcomes.
This issue also includes an article about
designing real-time process controllers.
Hardware-based automation and control sys-
tems are giving way to software-based con-
trol, according to the author. As he states:
“Almost all automation and control systems
are designed, developed, and built using data
processors, microprocessors, DSPs, or any other
processing device that executes instructions
derived or compiled from a software program.”
The third story expands on the concepts of the
enterprise information system maturity model.
The author provides advice on several aspects
of Level 1 sustainability, which include software
licensing, system/application extensibility, and
system openness, scalability, and support.
As AppliedAutomation enters its ninth year (the
first issue was published in August 2006), I wel-
come your thoughts and feedback. If there is a
topic you would like to see in AppliedAutomation,
or if you have a recent successful automation
project you would like to share, I would like to
hear about it. Send your ideas for topics and
success stories to jsmith@cfemedia.com.

ON THE COVER Some power analyzers have a motor option that integrates speed and torque signals, which enables them to be used to measure
electrical and mechanical power. Courtesy: Yokogawa Corp. of America

Applied Automation October 2014 • A3

 C O V E R S T O RY

Electrical power measurement

on 3-phase motors
Testing drive-and-motor systems is a three-step process.

3
By Bill Gatheridge Complete testing of a pulse width modulation
Yo k o g a w a (PWM)-based drive and motor system is a three-

I
Third step process. Step 1 is accurate measurement of
of three parts PWM VFD input and output power to identify drive
n the first part of this three-part series, we efficiency and power losses. Step 2 is accurate
examined basic electric motor power mea- measurement of motor input power. Step 3 is accu-
surements and analysis. In the second part, rate measurement of motor mechanical power.
we examined a three-step process for making preci- The optimum method is to integrate all three steps
sion electrical and mechanical power measurements using a single power analyzer to eliminate time skew.
on motors and variable frequency drive (VFD) sys- This provides excellent efficiency calculations as well—all
tems with complex and distorted waveforms, and how in a single software/hardware solution.
these measurements are used to calculate motor and Some power analyzers have a motor option in which
drive system efficiencies. In this third and final article on the speed and torque signals can be integrated in this
electric motor power measurement and analysis, we will manner. These power analyzers can measure electrical
cover power measurements for 3-phase ac motors and power and mechanical power, and send the data to a
drive systems. PC running software from the original analyzer manufac-
turer, or custom software from a system integrator (see
Lead Photo).

PWM drive measurements for ac motors

When using a PWM VFD to operate a motor, it is often
necessary to measure both the input and output of the
VFD using a 6-phase power analyzer. Not only can this
setup measure the 3-phase power, it can also measure
dc or single-phase power (see Figure 1).
Depending on the analyzer, the setup mode will be
performed in the normal or RMS mode. The wiring con-
figuration should be set to match the application, such as
3-phase input and 3-phase output.
Any line filter or low-pass filter should be off because
the filtering will obscure the measurements. However, the
zero-cross filter or frequency filter should be on because
it will filter the high-frequency noise so the fundamental
frequency can be measured. This measurement is neces-
sary when tracking the frequency of a drive.
Figure 2 shows a PWM output voltage waveform with
a highly distorted voltage, chopped high frequencies, and
a lot of noise on the current side, making for a difficult
measurement. High-frequency switching on the voltage
signal creates a much distorted waveform and with high

Lead photo: Some power analyzers have a motor option that inte-
grates speed and torque signals, which enables them to be used
to measure electrical and mechanical power. All graphics courtesy:
Yokogawa
A4 • October 2014 Applied Automation
Figure 1: This diagram shows a typical motor and drive test system.
harmonic content. The frequency varies from 0 Hz up to
the operating speed.
For such a noisy signal, special current sensors are
needed for measurement. Accurate PWM power mea-
surements also require wide bandwidth power analyzers
capable of measuring these complex signals.
Figure 3 is an example of the voltage harmonic content
from a PWM output. Beat frequencies are present, and
voltage harmonic content exceeds 500 orders (approxi-
mately 30 kHz). Most of the harmonic content is in the
lower frequencies on the current side.
PWM motor, drive measurement issues
Inverter voltage is typically measured in one of two
ways. A true RMS measurement that includes total har-
monic content can be used. However, because the fun-
damental waveform is primarily what contributes to the
torque of the motor, a simpler measurement can be made
and used. Most applications only require measurement of
the fundamental waveform.
There are two main methods for measuring the funda-
mental amplitude of the voltage wave. The first and sim-
plest is to use a low-pass filter to remove high frequen-
cies. If the power analyzer has this filter, simply turn it on.
Proper filtering will give an RMS voltage of the inverter
fundamental frequency. However, this type of filtering
does not offer a true total power measurement, so filter-
ing isn’t the most exacting method.
The second method is the rectified mean measurement
method, which delivers an RMS voltage of the fundamen-
tal wave without filtering by using mean-value voltage
detection scaled to the RMS voltage. The algorithm of the
rectified mean of a cycle average will provide the equiva-
lent of the fundamental voltage that will be very close to
the RMS value of the fundamental wave.
Using this method, the total power, total current, and
fundamental voltage can be measured.
Figure 2: This screenshot shows a highly distorted PWM output
voltage and current waveform with very high harmonic content.
Figure 3: This screenshot shows voltage and current harmonic
content from a PWM measurement.
Measuring fundamental wave amplitude
using harmonic analysis
The harmonic analysis function can be used to find
the true fundamental voltage by using a Fast Fourier
Transform (FFT) to determine the amplitude of each
harmonic component including the fundamental wave.
This gives an accurate RMS voltage measurement of
the fundamental wave. The latest power analyzers can
make simultaneous true RMS measurements along
with harmonic measurements.
In Figure 4, the “Urms2” (the RMS value on the PWM
output) is a very high number, and F2 (the mean value
of the fundamental) is somewhat lower. The value
“Urms3” (filtering the fundamental) provides a simi-
lar result. Finally, U2 (1) is obtained from harmonics
analysis or FFT calculations of the fundamental. F2,
Urms3, and U2 (1) provide results that are very close,
but the U2 (1) FFT calculation is considered the most
accurate.
Applied Automation October 2014 • A5
 C o v e r s t o ry
Figure 4: This screenshot shows voltage measurements for a PWM
drive.
Figure 5: This screenshot shows how to make accurate dc bus volt-
age measurements for a PWM drive. The cursor must lie across the
waveform to make an accurate measurement.
Inverter current is usually measured only one way, and
that is as a true RMS signal, because all harmonic cur-
rents contribute to and are responsible for temperature
rise in the motor, so all must be measured.
Another important measurement involves drive Volts-
per-Hertz (V/Hz). A PWM drive should maintain a con-
stant V/Hz ratio over the operating speed of the motor.
The power analyzer can calculate V/Hz using the RMS
or the fundamental voltage value. The analyzer’s user-
defined math function is used to develop an equation for
this measurement.
Measuring dc bus voltage
The dc bus voltage in the PWM can be measured to check
for over- and under-voltage conditions. This measurement
can be performed inside the drive on the terminals of the
capacitor bank. However, an easier method is to use a power
analyzer waveform display with the cursor measurement.
A6 • October 2014 Applied Automation
When performing the waveform display with the cur-
sor measurement, one must make sure the cursor isn’t
directly on top of the small spikes in the display. Instead,
the cursor must lie across the waveform to make an
accurate measurement. Figure 5 shows a PWM voltage
measurement with high-speed switching. The cursor is
placed to read a value, such as 302.81 V in this mea-
surement.
Mechanical power measurements
Mechanical power is measured as the motor speed
times the motor torque. There are many different types
of speed and torque sensors on the market that work
with a variety of motors. It is wise to confirm compat-
ibility in each case. These sensors can be used to
provide the mechanical measurement information to
calculate the mechanical power measurements in the
power analyzer.
Many sensors come with interface electronics to con-
dition the signal properly to work with power analyzers
or other equipment. The conditioned signal can be an
analog output, or a serial communication output that
goes to a PC and its application system software.
One option to implement mechanical power measure-
ments is to use both a sensor and a corresponding
measurement instrument from a given manufacturer.
This approach has advantages because the sensors
will be exactly matched to the instrument. Readouts for
torque, speed, and power will be available, and there
will likely be options for PC connectivity along with
associated application software.
A more integrated approach is shown in Figure 6.
With this configuration, the speed and torque signal
outputs from the sensor instrumentation are connected
directly to power analyzer speed and torque inputs.
This offers the big advantage of enabling electrical
and mechanical power measurements to be evaluated
simultaneously, and efficiency calculations to be per-
formed continuously.
Motor, drive, and system efficiency
Inverter efficiency in its simplest form is calculated as
output power divided by input power, and represented
as a percentage. One method used to measure input
and output power is simply to connect power meters on
the input and output, with the readings of the two meters
used to calculate efficiency.
A more comprehensive method is to use a multiple
input power analyzer to measure input and output simul-
taneously as shown in Figure 1. This results in a more
accurate efficiency calculation as it uses a single power
analyzer to eliminate potential errors caused by time
skew measurements.
With the internal math calculations provided by the
analyzer, a very simple, menu-driven computation can be
set up to calculate the drive loss and drive efficiency.
Which method should I use?
IEEE 112: Standard Test Procedure for Polyphase
Induction Motors and Generators is the U.S. industry
standard for motor testing, and it outlines several meth-
ods. Figure 7 shows a power analyzer display support-
ing “Method A” from the IEEE 112 standard in which all
mechanical power is divided by the total input to the motor.
The standard defines many parameters beyond the current
and motor voltage measurements, and it provides instruc-
tions for conducting and reporting generally accepted
tests for polyphase and induction motors and generators.
Additionally, the standard contains 11 test methods to
define how to make efficiency measurements in motors.
Test Method A—input-output defined by IEEE 112:
The efficiency is calculated as the ratio of the measure-
ment output power to the measured input power after Figure 6: A power analyzer can also be used to make mechanical
temperature and dynamometer corrections, if applicable. power measurements.
Tests are done at the rated load by the means of a
mechanical brake or dynamometer. This rating should be
limited to motors with full load ratings of 1 kW or less.
Test Method B—input-output with loss segregation:
In Method B, both input and output power measure-
ments are made, but various losses are separated out.
Most of these losses merely produce heat that must be
dissipated by the motor assembly and represent energy
that’s not available to perform work. This method is the
recognized testing standard for the U.S. motor industry
for motors with full load ratings of 1 to 300 kW.
While both Methods A and B work, Method B requires
a lot of instrumentation and is usually only performed by
motor manufacturers. Because most manufacturers use
Method B and most users prefer Method A, the efficien-
cy calculations between the two may differ. The motor
Figure 7: This screen shot shows how simultaneous electrical and
and drive manufacturers’ performance data may use dif-
ferent motor speeds, test loads, or other test conditions. mechanical measurements can be used to generate accurate effi-
ciency calculations.
Conclusion
Many items need to be considered when measuring A precision high-frequency power analyzer is an
power in an electric motor, such as total and true power important tool for measuring both mechanical and elec-
factor. These measurements involve complicated equa- trical power. Its analysis features and readings can help
tions, which is why most companies use a power ana- improve operations and even extend the life of a motor.
lyzer to generate these results automatically. Selecting the right analyzer and implementing it cor-
After the decision is made to use a power analyzer, rectly does require knowledge; however, if employed
decisions on the frequency range and accuracy level correctly, the power analyzer data will provide accurate
must be made. Instrument compatibility is another impor- and highly valuable results.
tant aspect in obtaining accurate readings safely, particu-
larly with current transformers. And this is an area where Bill Gatheridge is the product manager for power
the input/options on the analyzer must be considered. measuring instruments at Yokogawa Corp. of America,
Given correct sensor inputs, mechanical power mea- and has more than 25 years of experience with the
surements can also be made using a power analyzer. company in the area of precision electrical power mea-
Selecting the right speed and torque sensors is the first surements. He is a member and vice chairman of the
step in determining mechanical power. ASME PTC19.6 committee on electrical power mea-
Certain power analyzers also enable PWM measure- surements for utility power plant performance testing,
ments to be made. However, setting up the analyzer for a member of the RTCA/DO-160 committee for aircraft
PWM measurements also requires knowledge about how power testing, and has worked with an ASHRAE com-
currents and voltages will affect the power measurements. mittee on VFD testing.

Applied Automation October 2014 • A7

 REAL-TIME PROCESSING

Designing real-time
process controllers
The most important constraint in a real-time system is that the time it takes
to process an input and produce an output must be well known.

By Mario Torre Automation controllers must be real-time systems

Halliburton because they must control physical processes or plants

T
that demand real-time control. At this point, the automation
controller designer must have a very good idea of what a
oday, almost all automation and control sys- real-time system is.
tems are designed, developed, and built using Hermann Kopetz, in his book, “Real Time Systems:
data processors, microprocessors, DSPs, or Design Principles for Distributed Embedded Applications”
any other processing device that executes (2011), stated that “A real-time computer system is a com-
instructions derived or compiled from a soft- puter system where the correctness of the system behav-
ware program. Very few and specialized con- ior depends not only on the logical results of the computa-
trol devices still use plain hardware or programmable hard- tions, but also on the physical time when these results are
ware using a field programmable gate array to accomplish produced. By system behavior we mean the sequence of
the job for which they were designed. outputs in time of a system.”
Nevertheless, to design and develop software applica- For any physical plant to be governed, it requires a
tions for a controller or automation device, special skills controller capable of acquiring some input signals and pro-
and a good understanding of the automation and control ducing some specific output signals within a very specific
problem are required. time frame. If the controller
Many designers and pro- outputs occur outside such
grammers build web serv- time frame, those outputs
ers, information systems, will no longer be valid, and
business process manage- will produce malfunctions or
ment systems, and many even a catastrophic failure
other important and valu- in the physical plant.
able infrastructures based
on computing platforms. Figure 1: This diagram shows a simple control system. The output Real-time explanation
But when it comes to signal is produced t seconds after the input signal is introduced. How can we determine
industrial process control- All graphics and tables courtesy: Mario Torre that a computer system is a
lers, the designer recog- real-time system? Suppose
nizes that a new design and programming paradigm is there is a very simple system, with just one input and one
required. This is well accepted throughout the automation output. Such system generates an output signal every time
and control industry. it receives an input signal (see Figure 1).
Now, suppose that we repeatedly (but not periodically)
Real-time processing apply the same input signal to this system. We may
Similarly, many concepts involving signal acquisition, expect that this system will generate the same output
transducers, control setpoints, and others are related to signal every time, at exactly t seconds after the input
process-state variables, measurements, and control. But signal is applied. Unfortunately, this is not what happens
mostly, they are closely connected with real-time process- in actual controllers. The same output signal will be gen-
ing. The concept of real-time processing must be consid- erated by the controller every time, but the time t that it
ered when any engineer designs, develops, and deploys a takes the controller to produce each output may increase
new automation and control system. This is what differenti- slightly (see Figure 2). If we repeat this experiment, we
ates automation software designers from designers of any will find that the controller response times fall into a
other application software. It’s not better or worse, easier variation interval, say Δt. Some literature refers to Δt as
or harder; it’s just different. “latency jitter.”

A8 • October 2014 Applied Automation

 The question is: Who determines this magnitude Δt?
It strongly depends on how the controller hardware was
designed, which components were used, and how the
application software running inside it was designed and
developed.
It should be noted that the time magnitude t is not
related to the time variation value, Δt. The former depends
on the function that the controller is supposed to perform,
while the latter depends on how the designer implemented
this function inside the controller.
It is important to emphasize that no controller system
can reach Δt = 0. Therefore, the controller designer must
know the maximum that the physical plant would allow
without causing failures or damages, and consequently he
or she must build the right real-time controller that takes
into account such constraint.
Hard real time, soft real time
Depending on the physical plant and the type of control
to be performed, the controller may be classified as “hard
real time” or “soft real time.” If the specific characteristics
of the plant or process to be controlled are such that non-
compliance of the Δt constraint will produce a malfunction
or a failure, then the controller must be a “hard real-time”
controller.
If, on the other hand, the specific characteristics to be
controlled are such that noncompliance of its Δt constraint
will generate a degradation of the plant functionality, but
will not produce any malfunctions or failures, then a “soft
real-time” controller may be used.
Latency, reaction time
The value of Δt to be used as the main constraint for a
process controller design depends heavily on the nature
of the process to be controlled. Each physical process
has its own “latency,” that is, the mean time the process
reacts to a change in one or several of the inputs. This
latency is tied to the physical, chemical, and electrical laws
governing that process. For example, the latency of an oil
production process is very different from the latency of an
Table 1: Average latencies for
various processes
Process type Average latency
Oil production and transport 2 to 15 min
Water transport 2 to 5 min
Gas production and transport 30 to 60 sec
Electric power generation 4 to 16 msec
Telecommunications 2 to 5 msec
Nuclear power generation 1 to 2 msec
Military weaponry 100-200 microseconds
Figure 2: This diagram shows an input signal inserted repeatedly
into the system.
electric power transmission system. Average latencies vary
by process, which is one reason specific process knowl-
edge—as well as control engineering knowledge—is so
important (see Table 1).
Based on experience, a basic rule-of-thumb for automa-
tion controller design is that the controller’s Δt must be
at least 5 times smaller than the latency of the process
the controller is intended to govern. Of course, this also
depends on many other considerations, such as power
consumption, heat dissipation, available space, and many
other constraints not discussed here.
Designing a hard real-time controller is much more dif-
ficult than building a soft real-time controller. Depending
on the physical process and the specific application, the
designer must choose to build one or the other.
Most controllers for industrial applications available in
the market are soft real-time controllers. The good news
is that almost all industrial automation and control applica-
tions may be governed by soft real-time controllers. Only
in a few, very specific situations are hard real-time control-
lers justified and installed. But, as long as a good control-
ler is designed or chosen, in which its latency jitter Δt is
small enough compared to the process latency, a reliable
automation solution may be provided.
Designing the real-time controller
The most important constraint in a real-time system is
that the time required for processing an input and produc-
ing an output must be well known. In other words, the
processing time of a real-time system to get a solution
is part of the solution. Of course, for a particular system,
such time is not always exactly the same; it may vary.
This deviation, which we have called “latency jitter” or Δt,
essentially defines the “determinism” that a real-time sys-
tem is providing. The closer Δt approaches zero, the more
deterministic a real-time system is.
To be governed, any physical plant requires a real-time
controller, which is, per se, a real-time system. The con-
troller Δt must be at least 5 times smaller than the latency
Applied Automation October 2014 • A9
 REAL-TIME PROCESSING
of the plant. This is a very general rule-of-thumb, and
may be different depending on the application and other
considerations and trade-offs. However, the controller
designer must use a specific Δt when designing a real-
time controller.
So, now the question is: How can we reliably design a
controller that guarantees some specific Δt? For simplicity,
the discussion here will:
 Consider the design of an electronic controller
for a plant.
 Assume that all sensors, transducers, and
actuators are readily available, and that all inputs
and outputs are electrical signals.
 Consider that this controller will be a digital controller,
that is, analog-to-digital conversions are made, and
the control functions are being made by logical and
mathematical operations.
In brief, this controller will be developed using
(mostly) digital electronic components, PC boards, and
related parts.
The most basic approach for any electronic designer to
come up with a controller is to go with discrete components.
Any digital controller may be implemented using logic gates,
flip-flops, and buffers. Those components have a great per-
formance in regard to latency jitter. The Δt of most of those
components is very low (depending on gate technology, it is
about 40-50 nanosec), so the overall controller latency jitter
typically won’t exceed 1 microsec, which is good enough for
most real-time applications—even hard real time.
The main issue with this hardware approach is its lack
of flexibility and expandability. If there’s a need for an
extra input or a change to controller functionality, then a
new controller must be designed. However, it is important
to say that this hardware approach was widely used in
the past, and it is still being used in very specific applica-
tions—most of them in the hard real-time domain.
t4
Application
t3 t5
Programming framework
Operating system
t2 t6
t1 Hardware t7
Input events Output actions
Figure 3: This diagram shows controller design processing layers.
A10 • October 2014 Applied Automation
To date, almost all digital controllers are microprocessor-
based controllers. The designer is no longer entitled to
build the hardware for a controller. Controller hardware
has been standardized, and all signal treatment, filtering,
and processing are managed by microprocessors. Most
of them have several processing cores, depending on the
type and purpose of the controller. It may sound simple,
but to date the work of a controller designer has been
reduced to:
 Selecting the right controller hardware according
to the application
 Choosing the operating system to be used
 Selecting the programming environment or framework
that will further help with the development
 Developing a software application to implement the
actual controller function that is needed for the plant
that the control designer envisions to control.
Selecting the right hardware controller for the application
may be, by itself, a complicated task. The characteristics
of hardware controllers will depend on the elapsed time t
required for the controller to provide the solution, and the
latency jitter Δt that is expected from such controller. It is
also determined by many other factors and conditions that
go beyond considerations here. For this discussion, let’s
say that the correct hardware selection criteria will need to
meet the following requirements:
 Must be fast enough to handle the required
elapsed time and latency jitter
 Must be able to handle processor interrupts
in real-time
 Must provide an “adequate” development and run-
time software environment in which the designer can
design and deploy the required software application.
After the hardware is selected, the designer creates the
software application using a computer language accord-
ing to the chosen software development environment.
Currently, hardware controllers include a rich, intuitive
software development environment, where applications
may run over some specific operating system and a pro-
gramming framework. Although it is not mandatory, the
use of the hardware manufacturer’s suggested program-
ming framework is advised. Please note that designing
software applications without using any software environ-
ment is similar to building the hardware out of discrete
components and chips, as explained earlier.
Suppose that the designer already selected the hard-
ware and is about to design a new software application
on top of the selected operating system using a program-
ming language. Depending on the programming language
preferred, there may be more software layers between
the hardware and the actual controller application: frame-
works (such as Microsoft.NET), virtual machines (such as
Oracle Java), or even hardware manufacturer proprietary
frameworks or programming interfaces.
 QUALITY X PERFORMANCE X MACHINE AVAILABILITY = OEE

INCREASE YOUR OEE

Motion Control AC Drives Robotics

Drive your overall equipment efficiencies higher with motion-

centric solutions from Yaskawa.

• Contain large data arrays for recipe management and higher SEE IT ALL COME TOGETHER
servo axis count. Booth# S-1733
• Higher performance through electronic camming.
• Change cam profiles on the fly.
• Ethernet IP and PackML for machine-to-machine productivity. PACK EXPO International
November 2–5, 2014
Chicago, IL USA
Looking for performance greater than what you have now?
Call Yaskawa today.

YA S K A W A A M E R I C A , I N C .
DRIVES & MOTION DIVISION
1 - 8 0 0 - YA S K A W A YA S K A W A . C O M

Follow us: For more info:

http://Ez.com/yai686 ©2014 Yaskawa America Inc.
 R e a l - t i m e pR o c e s s i n g

Table 2: Controller application time components

Time slice Description Characteristics Recommendations

t 1, t 7 Hardware latency: Time since the
occurrence of the interrupt or polled
signal to the moment the operating
system starts attending to it; or time
since the operating system reception
of the output signal request to the
moment the actual output is
produced.
t 2, t 6 Operating system latency: Elapsed
time from when input signal was
detected from the operating system to
the moment the event is sent to the
programming framework for service;
alternatively, time from when an out-
put signal request is received from the
framework until the operating system
schedules it for output.
t 3, t 5 Programming framework latency:
Elapsed time from when an I/O event
is detected in the framework until such
event is first attended to or generated
by the application.
t4 App processing time: The actual
elapsed time of the controller
application.
n Depends on CPU memory and I/O system
(hardware) speed
n May be deterministic (very low ∆t)
n Depends on signal type and how it is
handled by hardware (interrupts, A/D
conversion, polling); depends on how the
operating system handles interrupts
(interrupt service latency time)
n Determinism depends heavily on operating
system scheduling policies and internal
architecture
n Yield ∆t depends on operating system
internal time slice interval, or “tick”
n Determinism may be seriously compromised
by framework performance
n Determinism depends on the software
application architecture, design, and
implementation
n Performance will be governed by
application-assigned operating system
priority and availability of resources
n Properly design or assess selected hardware,
focusing on CPU, memory and I/O speed, interrupt
handling, and interrupt latency times
n Select the operating system that provides an
adequate interrupt service latency time
n Avoid polling for input signals whenever possible
It is important to select the operating system best
suited for the application
n Select the operating system best suited for
real-time applications
n Operating system tick interval must be 10 times
smaller than the desired ∆t
Select the programming framework designed for
real-time applications
n Assess programming framework benchmarking
tests, focusing on latency and response times
n Based on the application and ∆t desired, use of
programming framework will not be recommended
n Software design, development, and implementa-
tion must be in accordance with asynchronous,
concurrent real-time best practices
n Application design must fully leverage and
exploit the selected language, the programming
framework, the operating system, and the
controller hardware

All these layers further separate the controller applica-
tion from the input and output signals. Also, it must be
noted that each of those layers adds latencies and pro-
cessing times. Figure 3 shows the processing layers for a
typical controller implementation.
As displayed in Figure 3, an input event must be han-
dled from its occurrence, through all the layers, up to the
actual application that will process it. After it is processed,
the application must send the results to the actual output
port, which also must go through the same layers. The
total response time for this simple control application,
using the above stack of hardware and software layers,
can be calculated as:
t = t1 + t2 + t3 + t4 + t5 + t6 + t7
However, under this scenario, how can the designer
guarantee that the total response time t will be the
required one for the plant? How can the control designer
ensure that such response time will be within a specific
latency jitter ∆t? Table 2 shows a detailed explanation
of each time component and how each one affects Δt
and also gives some initial recommendations on how to
achieve the desired results.
Each of the time components mentioned above provides
a portion of the total resulting controller latency jitter Δt.
One of the controller designer’s main duties is to assess
every one of those components, and adequately weight
them to make sure that:
n Resulting controller latency t is the required one
n The sum of Δts from all time components will not go
beyond the desired latency jitter.
This is not an easy task. Please note that what is
exposed in Table 2 is a very simplistic first view of a real-
time controller design. There are many more consider-
ations that must be made by the controller designer and
assigned team that also affect selections of hardware,
operating systems, and frameworks far beyond the strict
real-time performance of the controller.
Mario Torre is a real-time systems design and architect
specialist, focused on digital oil field automation, control,
and real-time information systems. He is an electronics
engineer with a master’s degree in systems engineer-
ing. He is currently a consulting advisor in the Intelligent
Operations Solutions Global Group at Halliburton
Landmark Software and Services in Houston.

A12 • October 2014 Applied Automation

 E N T E R P R I S E I N F O R M AT I O N S Y S T E M S

Migrating toward enterprise

information systems
Maturity model advice helps organizations move from Level 0, paper-based systems
and homegrown systems, to Level 1, focused data systems. Maturity models applied
to processes and software help increase decision efficiency, because greater decision
efficiency = lower costs = higher profits.

By Corey Stefanczak Reaching the primary goal

Leidos of sustainability

U
sing a maturity model pro-
vides advice to assist a
business owner moving
processes and software
from Level 0 (paper-based
systems or homegrown systems) of
the model to Level 1 (focused data
systems) (see Figure 1).
Great place to start Figure 1: More mature information systems
The good news is that Level 0 require more investments, and a significant important to evaluate licensing models
applications make up a large number and carefully coordinated investment. All
of applications, and moving to Level 1 graphics courtesy: Leidos
is a common activity within the matu-
rity model. The bad news is that the homegrown Level 0
applications are almost always disbanded in the process.
It’s important to understand that this is a natural evolu-
tion of maturity. The scope of the maturity model is not
typically envisioned when Level 0 applications are built.
However, the work performed on these applications isn’t
wasted effort. In some cases, it is the only way to under-
stand what is needed (either by the success of the appli-
cation to fill a specific need or by recognition of a need
that went unfilled). This makes Level 0 systems a great
place to start when developing requirements for an enter-
prise-level system.
Quick recap, context
The enterprise information system maturity model
was introduced in the article, “Understand the maturity
model to better manage, integrate plant floor, enterprise
systems,” (Control Engineering, Aug. 2014). This model
presents a general context for understanding enterprise
systems. Most importantly, it provides a set of criteria to
evaluate your enterprise system needs and help deter-
mine next steps to increase decision efficiency (and the
bottom line). In effect: greater decision efficiency = lower
costs = higher profits.
The primary reason for making the
leap to Level 1 is the overall sustain-
ability of the system. Sustainability is
primarily affected by the choice of the
application platform for the system.
The following offers advice on several
aspects of Level 1 sustainability.
Licensing: Licensing can be a road-
block to maintaining and operating an
enterprise system. When selecting a
platform to build a Level 1 system, it is
to identify any restrictions or limita-
tions. Some software uses more com-
plex models, which may restrict access
to configuration and management tools. These restrictions
often provide a competitive advantage for the integrator or
vendor to gain future work updating the system.
Here are some key issues to consider:
 The availability of configuration and management soft-
ware should not be limited to the system integrator
performing the implementation. The owner and other
system integrators should be able to access and config-
ure the software.
 Be wary of any licenses that restrict connectivity to a
“vendor-locked” version of configuration and manage-
ment software.
 System licenses should not restrict communication to
other third-party devices or applications that are not of
an approved brand. This is not a technical limitation,
but rather a tactic used by vendors to prevent future
integration of competitors’ products into the existing
system.
 Some applications require a physical device, such as
a USB key, to be present to properly license a system
for operation. Hardware keys are susceptible to being
stolen, and issues can arise when interfacing the licens-
ing hardware in a virtual environment. Systems should
provide software key licensing.

Applied Automation October 2014 • A13

 E N T E R P R I S E I N F O R M AT I O N S Y S T E M S
Openness: “Open” is a common buzzword that can
have several meanings. First, it can refer to the avail-
ability of vendor support and configuration. Systems can
be deployed so they are serviceable only by a single
vendor through controlled proprietary knowledge. These
“closed” systems force the owner to rely on a single
vendor and limit the owner’s ability to obtain competi-
tively priced services.
The second meaning of openness is the ability to com-
municate and integrate with third-party systems. Here are
some questions to ask when examining system software:
 Does the system rely on proprietary protocols to com-
municate to devices and other systems?
 Does the system store historical information in a propri-
etary database? If so, are standard interfaces available,
such as Web services or open database connectivity, to
allow data access from third-party systems?
 Does the system support exporting data into industry
standard formats such as comma separated variable
(CSV), Microsoft Excel, or extensible markup language
(XML) files?
Figure 2: Moving to higher software maturity model levels (0 to 4)
requires additional investment and can result in more efficient decision
making that reduces cost and improves productivity.
Open communication is crucial when augmenting the
system. Systems that don’t provide standard interfaces
increase the complexity of future integration and provide
lower overall value (see Figure 2).
Extensibility: The full usefulness of a system is rarely
realized during the initial installation and use. Systems are
generally selected and installed to fulfill specific objectives.
It’s common for future goals and requirements to dictate
changes to existing systems. The goal is to select applica-
tions that not only offer a set of features, but also provide
a platform on which the system may be enhanced and
extended.
There are several guidelines to use when evaluating the
extensibility of a system:
 Does the system provide programming software, a
software development kit (SDK), or an application pro-
gramming interface (API) to support third-party devel-
oped modules?
A14 • October 2014 Applied Automation
 What is the extent of the features that may be accessed
through an available API or SDK? Is read/write access
to data possible? Are other system functions available?
 Is the system modular? Is it possible to buy what you
need now and add functionality later?
 If third-party modules or extensions may be developed
for the system, what are the development require-
ments?
 How accessible are the tools and training, if needed?
Does the system vendor provide training or certification
programs?
As a general rule, systems that support extensible frame-
works are more flexible and provide better value over the
life of the system.
Scalability: In contrast to extensibility (which refers to
new system features), scalability signifies the ability to
add capacity to the system using the existing features. For
example, a manufacturing control system is scaled by add-
ing a new controller. It is extended by a adding a new pro-
cessing feature that was not previously available.
It’s important to understand short- and long-term goals
when selecting a platform. Typically, a system supports the
necessary capacity at the time of the deployment. However,
the ability to support future capacity needs to be under-
stood. Be sure to select systems that may be rapidly and
cost-effectively expanded to meet users’ growing needs
without adversely affecting system performance. It is also
important that a system provides features to easily manage
and configure system components.
Support: The long-term success of a system depends
greatly on the ongoing support structure for hosting, mainte-
nance, and troubleshooting. The support responsibilities of
the owner and system provider need to be clearly defined.
The following questions help determine how responsibilities
should be divided:
 Can routine maintenance activities be performed by the
owner/third party?
 Can disaster recovery procedures be performed by the
owner/third party?
 Can the IT resources at the installation site support the
system hardware, operating system, and application
software?
 Can local resources support the hosting, backup, and
redundancy requirements or should some or all of the
support responsibilities be outsourced to a third party?
What’s next?
After an owner has successfully implemented Level 1
systems, the next step is to gain a competitive advantage
of centralized data with Level 2 maturity. Level 2 maturity
enables businesses to correlate information across their
systems and make key insights into their operations.
Corey Stefanczak is a senior system architect at Leidos.
 Our MOVIDRIVE ®

is Sexi-lingual!
That’s right...our MOVIDRIVE inverter can
speak at least six fieldbus languages. It
can also substantially reduce the load from
your main PLC and drastically improve its

performance - all with zero programming!

Now, you can forget about C++ or C#. Simply

enter your parameters and go. We understand

that a fieldbus system is a large investment.

So, keep your bus and leave the driving to us!

seweurodrive.com / 864-439-7537
 Upgrade your Remote I/O™
System to EtherNet/IP™

with minimum
downtime!
Using ProSoft’s Remote I/O to
EtherNet/IP™ gateway and our
Blue Hose Industrial Media Converters
For more information,
visit psft.com/eiprioapplied1

Where Automation Connects +1-661-716-5100

www.prosoft-technology.com

A SIA PACIFIC | AFR IC A | EUROPE | MIDDLE E A S T | L ATIN AMER IC A | NOR TH AMER IC A