November 17
10
I
ndustrIal
C
omputIng
& C
ommunICatIon
Smoothing out interoperability issues
in smart factories
By Edward Lin,
Moxa
This article takes a closer look at
the challenges that system
integrators face with Operation-
Technology-to-OperationTechnology,
OperationTechnology-to-Information-
Technology and OperationTechnology-
to-IIoT interoperability, as well as the
solutions available to ensure
nonstop connectivity throughout
converged networks.
n
While discussions about the Industrial
Internet of Things (IIoT) and its promises
of cost-efficient, nonstop operations carry
an opportunistic tone among executives, it is
system integrators (SIs) who have to grapple
with the reality of figuring out how the dif-
ferent platforms in a network can commu-
nicate with each other. What turns SIs world
upside down is the hodgepodge of protocols
in the three divergent domains of network
architecture: Operation Technology (OT),
Information Technology (IT), and the IIoT.
Each domain comes with its own set of pro-
tocols that effectively creates non-interopera-
ble silos, making it impossible for useful data
to reach those who need it on an enterprise
level to make important decisions, and leav-
ing SIs at their wit’s end. Matters are further
complicated by the fact that both the OT
and IT departments are unfamiliar with the
protocols used in each other domains. This
trend must be reversed quickly, because as
the IIoT makes inroads into automation, OT
and IT are converging. There is good news,
though. Solutions are available to bridge these
interoperability issues through a variety of
protocol conversions.
OT-to-OT communications in factories are
not as simple as they used to be. This can
mostly be attributed to the IIoT, which has
brought gazillions of sensors and machines to
the Internet on a massive scale. These types
of communications are not going to get sim-
pler anytime soon, as the rise in connected
IoT devices is expected to jump by 15% in
2017 to reach a whopping 20 billion, accord-
ing to a new report from IHS Market. This
surge to get connected is impacting factory
floors in such a big way that M2M commu-
nications have evolved into communications
between divergent operational subsystems to
fulfill data collection and analytics. The snag,
however, is that the heterogeneous systems
that fall under OT, such as manufacturing
executive systems (MESs), supervisory con-
trol and data acquisition (SCADA) systems,
programmable logic controllers (PLCs), and
the machines and sensors on the plant floor,
all run their own protocols; consequently, the
age-old issue of non-operability rears its head
again and a multitude of protocol conversions
are required.
A good example of where efficient commu-
nications between disparate OT systems on
the factory floor benefit operations is having
the heater, ventilation, and air-conditioning
(HVAC) system work in sync with the pro-
duction system. When the workload of the lat-
ter increases, it alerts the former to start up to
ensure that production will not be interrupted
by overheating or freezing temperatures. The
growing complexity of operations processes
brings more and more heterogeneous systems
into the equation. This means more devices
and more protocols. Installation and setup
require more time to plan the architecture
and perform device commissioning. For SIs, it
is all about saving time and costs. They don’t
want to spend long hours on device commis-
sioning and configuration, or on protocol
conversions. However, it is not uncommon
for them to spend hours on communication
and troubleshooting programming when
using communication modules or small PLCs.
Thus, SIs want an easy way to simplify proto-
col conversions so that they can rather spend
their limited time on their core tasks, such as
programming.
More and more operators are taking advan-
tage of industrial protocol gateways to accom-
plish the mass configuration of devices and
protocol conversions between different
devices to keep operations running smoothly.
For example, in an electricity room, bridg-
ing a large number of Modbus RTU power
meters to a Modbus TCP network is usually
extremely time-consuming due to the con-
figuration of the slave ID routing table. A
convenient solution includes an auto device
routing function that automatically detects
the commands from a SCADA system and
sets up the slave ID routing table. With only
one click, this configuration can be achieved
Figure 1. There are many proto-
cols used in the industry.
