Thanks Arlen. This is
getting to a broad
class of problem that the IWG could tackle.
Would you walk us through a
scenario
you have in mind on the call today?
.................Scott
From:
Arlen Nipper
<arlen.nipper@xxxxxxxxx>
To:
m2m-iwg@xxxxxxxxxxx
Date:
06/05/2012 08:31 AM
Subject:
[m2m-iwg]
M2M-Problem-0003
Sent by:
m2m-iwg-bounces@xxxxxxxxxxx
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
_______________________________________________
m2m-iwg mailing list
m2m-iwg@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/m2m-iwg
_______________________________________________
m2m-iwg mailing list
m2m-iwg@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/m2m-iwg
