For discussion in our call today. Will get posted onto the Wiki
later today.
Arlen
M2M-Problem-0003
– “One to One” data model for SCADA/Telemetry information.
Legacy SCADA(Supervisory Control and Data
Acquisition) and
Telemetry systems probably represent one of the single largest
markets of
existing sensors, actuators and smart devices that the M2M market
is starting
(wanting) to target. In this context, one of the greatest problems
to overcome
is the “SCADA Data Cage” scenario where “Device” applications are
coded to talk
directly to corresponding “Host” applications. The result is that
what could be
a wealth of device information shared across an enterprise becomes
captured in
the host application and becomes difficult if not impossible to
extract, share,
and extract business value and analytics from. In large part this
is due to
legacy protocols that have been developed over the years for each
of the remote
devices installed in the field. In fact protocols in this context
are the
single biggest issue when used in any SCADA/Telemetry/M2M
infrastructure. From
a legacy point of view device protocols typically encapsulated
both the
“transport” of the data as well and the “data representation”.
With this being
the case you cannot break up the transport of the data from the
data itself.
M2M-Problem-0001 touched on this issue with a
few examples
of :
·
Modbus
·
SAE J1939
·
Continua Medical Device
Profiles
But in actual fact there are literally hundreds
of these
types of protocols in use today and for many years to come. The
Problem and the
related SCADA Scenario are
intended to
be representative of a larger class of other M2M and IoT solutions
where device
data and protocols can become too tightly coupled to the
applications.
Take for example the Modbus Protocol. Modbus is
probably one
of the most popular and widely used device protocols in the
industrial market
today. It is a Poll/Response protocol that strictly defines unit
addressing,
function code definition, and data representation within each of
the Poll or
Response data packets. Initially designed primarily for RS-232/485
Poll/Response networks it has served its purpose well. But
consider the fact
that now we would like to take the data from a Modbus response and
share it
with multiple data consumers, quickly and easily. Since by its
very nature
Modbus requires that a Host application formulate and send a
proper poll
message and then receive, validate, and parse the resulting data,
this very
process now relegates the data to the host application that
received it. To
share it with any additional data consumers that want access to
the parameters
requires additional coding. This problem holds true for the
majority of other
poll/response protocols and infrastructures in place today. (Note
that
M2M-Problem-0001 has already addressed the issue of information
discovery of
these types of protocols and did elude to a producer/consumer
model and can be
extended to many other legacy protocols as well.)
Fielded
solution
patterns.
This problem and been around for decades and
has many
fielded solutions. Most solutions have proven to work over the
years but tend
to be "point in time" solutions that become brittle and
problematic over time.
All of these solutions require additional compute resources,
coding,
configuration, and management overheads.
FEPs (Front End Processors) – FEP were
and still are
very prevalent in these types of network infrastructures. FEP’s
are basically
standalone computer applications that are responsible for the
polling of
devices, validating responses, and then taking the resulting data
stream and
applying the transformations required to send the data to the next
processing
element in the food chain. Typically the next element would be the
SCADA host
system. Any change in downstream data consumers would typically
result in the
re-configuration if not application development on the FEP.
Relational Database Query – In many
systems, the host
SCADA/Telemetry application will place the resulting process data
into a
relational database for historical and archive purposes. This
database can then
be used as a data source for other consumers of the data. Again,
this becomes
problematic if additional data needs to be added to the schema
that was not
originally specified. In many cases, if the operations side of the
business
does not need the data, there may not be any interest in acquiring
it in the
first place.
Field Protocol Converters/Gateways – In
many fielded
solutions existing device equipment is front ended by a protocol
converter or
gateway locally. This could be considered some of the earliest
“M2M Device
Platforms” and has become a very viable solution to the problem.
These devices
can typically handle the local physical interface requirements
(RS-232/485/422/Ethernet/CANbus/HART) as well as converting device
data into a
more common transport protocol. But many still deliver the
resulting data
stream in a proprietary format and still expect a host application
to consume
the results.
Related
Scenarios
M2M-Scenario 0002
M2M-Scenario 0001
Referenced
by Problems
None