Publish/subscribe ethernet fieldbus protocols

D

Thread Starter

Damon Maria

Does anyone know of ethernet fieldbus products that use a publish/subscribe protocol. By this I mean the data acquisition module pushes data input changes to the controller over ethernet (preferably TCP/IP) therefore eliminating the need for polling.

I've looked at so many different products recently but only one I've found so far (National Instruments FP-1600) implements this model of protocol. But it's not an open or documented protocol, arrrrgh!

This seems to have so many obvious advantages to me that I can't see why everyone hasn't used it for their ethernet protocol. It elmininates the need of polling, gets the input data to the controller faster, and frees up the controller to just sit and wait for the data to come in.

Am I missing something here? If anyone could point me to another product that implements this protocol model (and is an open protocol) I'd be very appreciative.

regards,
Damon.

 
P
A protocol that fits your description is DNP 3.0

It is an open standard. Protocol specification is available to members of the DNP User Group (http://www.dnp.org/). The quiescent unsolicited mode of operation is very efficient, Only changes are reported, it can transfer large amount of data using very little bandwidth. Works over serial link, TCP/IP or UDP/IP

[email protected]
http://www.ioserver.com/
 
P

Peter Whalley

Hi Damon,

The EIA 709.1 protocol (was Lonworks) supports both polled and bound or
"report on change" type operation. With the latter, the source is configured with a list of destinations which it notifies whenever the value of the source changes.

Note that EIA709.1 does not have any intrinsic ability to set a change of
value deadband on analogue values so if you have a noisy signal you may need to pre-filter it or program in some type of deadbanding to prevent excessive traffic being generated.

EIA709.1 can be run over Ethernet and products to do this are available from Echelon, Coactive and CTI Products, Inc. Unfortunately I don't believe the standard for encapsulation in IP has been ratified as yet so interoperability between these products is not guaranteed.

Regards

Peter Whalley
 
R

Rob Hulsebos Philips CFT

>Does anyone know of ethernet fieldbus products that use a
>publish/subscribe protocol. By this I mean the data acquisition module
>pushes data input changes to the controller over ethernet (preferably
>TCP/IP) therefore eliminating the need for polling.

Although not a fieldbus, NDDS of RTI (www.rti.com) does work as described.
I say "not a fieldbus" but it will be part of the IDA bus.

>This seems to have so many obvious advantages to me that I can't see why
>everyone hasn't used it for their ethernet protocol. It elmininates the
>need of polling, gets the input data to the controller faster, and frees
>up the controller to just sit and wait for the data to come in.
>Am I missing something here?

publish/subscribe protocols have their disadvantages, too. In order to counter this, more sw if needed than just for the "publish" part. This makes it more complex than say, a master/slave protocol. Nothing simpler than (for example) a Modbus slave being polled by a master!


Rob Hulsebos
 
I think that CTI (Control Technology, Inc) makes and ethernet module for
the SIMATIC 505 Processor that uses Publish/subscribe.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Don Best, PE
[email protected]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
C

Curt Wuollet

I'd be interested in _any_ truly open Ethernet automation protocol. For LPLC, it looks like we may have to write one since we can't coax any of the "open" vendors to actually open theirs, even for the marketing bragging rights of being the first. I'm sure you can see why we don't want to do that but, it may be the only way.

Good Luck

Regards

cww
--
Free Tools!
Machine Automation Tools (LinuxPLC) Free, Truly Open & Publicly Owned
Industrial Automation Software For Linux. mat.sourceforge.net.
Day Job: Heartland Engineering, Automation & ATE for Automotive
Rebuilders.
Consultancy: Wide Open Technologies: Moving Business & Automation to
Linux.
 
R

Rob Entzinger Schneider Automation

What do you want to publish/subscribe?.

For everything you publish, eg a trip. You require software somewhere to receive the message
and act accordingly.

Rob E.


 
C

Chuck Miller

Rob -

Do you still keep a running list of the field bus URLs? If so, can you send me the most recent list?

Chuck Miller
GE Fanuc Critical Control Business Leader
(281) 495-0333
Fax: (281) 495-0370
email: [email protected]

 
L
(Not to start any 'war' over the word publish/subscribe or producer/consumer - they have subtle differences but accomplish the same
Multicast function)

This "KISS" idea (keep-it-simple-stupid) of Modbus/TCP is true for Master-Slave, but in a peer to peer design the multicast offers less than
1% the traffic.

My simple Powerpoint example is for 25 "peers" to use Modbus/TCP once a second all day to update each other with data requires about 8,600,000 TCP
packets per day. This includes running 24 sockets from each to his peers, poll/requests per second, and TCP acks. This amount can be reduced if one
peer acts as "master" to collect & distribute packed data to the other 24 as "slaves", but this offers it's own added complexities to pack, unpack, and manage both slave & master-failure/recovery in a centralized manner.

The same 25 peers could accomplish the same with UDP multicast (like GE's EGD, or CI/ODVA's Ethernet/IP, or IDA's NDDS) with about 90,000 packets per day (about 1% the load). Failure of any of the 25 peers requires no special recovery & fits the normal Publish/Subscribe scheme fine.

The consumer/subscriber part is also more complex in that it needs to maintain timers to recognize failed producers/publishers. I suspect in most
large systems added firmware complexity will be a welcome tradeoff for a 99% reduction in base traffic.


Best Regards

Lynn August Linse, [email protected] http://www.linse.org/lynn
3 Rue Monet, Foothill Ranch CA 92610
Ph: 949-300-6337 Fx: 612-677-3253
 
R

Ralph Mackiewicz

Publish/suscribe is not the only way to eliminate the need for polling. Report by exception can also accomplish this. Many protocols support report by exception including UCA/IEC61850 and DNP3 to name just 2.

Publish/subscribe is something different. I believe that Ethernet/IP supports this.

Best Regards,

Ralph Mackiewicz
SISCO, Inc.
 
F
You might take a look at LonWorks technology from Echelon. The LonTalk protocol is such a publish/subscribe model and it is an open protocol
(EIA-709). While most LonWorks devices are not natively IP, they implement the LonTalk protocol in Neurons and communicate over a variety of media. Echelon does make a device called the i.Lon 1000 that is a media router that communicates over IP. So just like you browse a website using http over IP, you can communicate via LonTalk over IP. This can be very cost effective since the LonWorks devices do not carry the burden of implementing IP, the only burden is in the router.

If you have questions or need assistance, feel free to contact me. I provide LonWorks based consulting services and you can find details on my
website http://www.grahamcontrols.com . You can find details about LonWorks on my website as well.

Regards,

Fred Graham
Graham Controls Consulting
Specializing in LonWorks technology
www.grahamcontrols.com
770.887.9024 (voice)
770.216.1668 (fax)
[email protected]

 
R

Richard Theron

Try the following two protocols, both across Ethernet, Sorry they are the opposition

1) GE-EGD
2) AB-Ethernet IP.

If you need a bridge to these protocols you know who to call, Not Ghost Busters, www.fieldserver.com

Regards

Richard Theron

 
R

Rob Hulsebos Philips CFT

I once had an analog input which apparently had a cheap A/D converter, so the last bit flipped in a random fashion. The I/O module thought it had to send the value of the input channel on each change, which generated a lot of useless network traffic.

The solution was to mask off the last two bits, but now we didn't have the promised 12-bit resolution anymore ;-( Another solution is to calculate a running average.

Another issue pops my mind. When an input does not change for a loooooong time, all producers are not sent new values (as there is none). But if a new producer is added to the network during
this interval, it is unaware of the state of all variables produced until they are all sent at least once. To counter this unwanted behaviour, a new producer must enforce that all variables it
needs are produced 'on command'. This may give a burst of network-traffic.

Rob
 
J

Johan Bengtsson

One disadvantage would be that if something goes wrong (for example the cable gets damaged by something) there is no way for the controller to
know that, a polling protocoll would notice that it didn't get a reply and could take proper action (like fireing an alarm or something)


/Johan Bengtsson

----------------------------------------
P&L, Innovation in training
Box 252, S-281 23 H{ssleholm SWEDEN
Tel: +46 451 49 460, Fax: +46 451 89 833
E-mail: [email protected]
Internet: http://www.pol.se/
----------------------------------------
 
F
This isn't necessarily so. With LonWorks, if a device is designed to the LonMark Interoperability Standard then each device implements a "heartbeat" with a programmable heartbeat timer. This allows the integrator to decide if a heartbeat is needed and how often it should occur. Basically the heartbeat is transmitted at a fixed interval if the value has not changed in that time. This eliminates the need for polling devices to see if they are alive.

Fred Graham
Graham Controls Consulting
Specializing in LonWorks technology
www.grahamcontrols.com
770.887.9024 (voice)
770.216.1668 (fax)
[email protected]
 
R

Ralph Mackiewicz

> I once had an analog input which apparently had a cheap A/D
> converter, so the last bit flipped in a random fashion. The
> I/O module thought it had to send the value of the input channel
> on each change, which generated a lot of useless network traffic.
>
> The solution was to mask off the last two bits, but now we didn't have
> the promised 12-bit resolution anymore ;-( Another solution is to
> calculate a running average.

The better solution for this type of situation (other than using better A/D converters) would be to use deadbanding to eliminate unnecessary or meaningless change reports. This is a common feature of report by exception systems but perhaps is not universal.

> Another issue pops my mind. When an input does not change for a
> loooooong time, all producers are not sent new values (as there is
> none). But if a new producer is added to the network during this
> interval, it is unaware of the state of all variables produced until
> they are all sent at least once. To counter this unwanted behaviour, a
> new producer must enforce that all variables it needs are produced 'on
> command'. This may give a burst of network-traffic.

I don't recall seeing any responses from the Ethernet/IP camp posted (maybe I just missed it). It would be interesting to see how Ethernet/IP handles these issues. The lack of specific Ethernet/IP information is curious given its focus on the publish/subscribe model.

Handling the update of new consumers and providing indications to consumers regarding the health of the producers are common requirements for implementing useful publish/subscribe systems.
Having consumers implement watchdogs, as was described for LONworks, is one way of doing it. The other is to utilize management systems to
track the health of the overall system and publish status messages regarding all components, including new producers and consumers. This
kind of technology is used in many enterprise application integration (EAI) environments. Keeping the consumers simple (because they are
complicated enough without having to manage the communciations functions) is imperative in these EAI systems.

This issue is addressed in report-by-exception systems using an integrity scan. Each node sending reports will periodically send all of its data, even if it didn't change, to ensure that all receiving nodes have current data.

Regards,

Ralph Mackiewicz
SISCO, Inc.
 
Top