[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [m2m-iwg] M2M-Problem-0003
|
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