Producer-Consumer Architectures for PLCs

M

Thread Starter

Mike Chivers

My company is in the process of migrating or replacing an old PLC/DCS system. One of the frustrating features of the current system is the resolution of alarm time-stamping is effectively limited by the approx 1s update rates of the PLC statuses into the DCS. This makes analysis of cause and effect more difficult because we have to take into account the delays between events and the alarm being registered.

We are not after substation style SOE reporting, just something that is a bit closer to the scan time of the PLCs.

Is anyone aware of PLC systems that support time-stamped report-by-exeception style communications or a more sophisticated producer-consumer model? While this is obviously more complex it seems like a much better approach to event recording that the poll-as-fast-as-you-can approach.

I thought AB/Rockwell did something like producer-consumer to get timely event transfer between the PLC and HMI (ControlNet and Ethernet/IP protocols). Are there other examples in leading PLC systems? Thanks.
 
Normally all DCS should have date & time
stamping for alarms at control processor level & OWS should only display it & not carry out alarm event logging at MMI.

Check with ABB 800M series DCS system.
 
M
With a little logic (ladder or otherwise), any PLC can time-stamp and store events at PLC scan time resolution. We do it almost everyday with Schneider (read MODICON) PLC's of all kinds - look for SER (Sequence of Events Recorder).

Your problem has two aspects:
A. How to record and time-stamp events IN the PLC (data space) - see above.
B. How to get that information FROM the PLC into whatever - this is a communications protocol issue and Producer/Consumer is not necessarily the answer. Once the events are time-stamped in the PLC, you can extract them from the PLC at (almost) any time later.

Meir
 
J
I would say that time-stamp is a different issue from producer/consumer

1. The FoundationT Fieldbus also has producer/consumer communication relationship although it is called publisher/subscriber it is the same thing as far as I can tell.

2. Since the producer may only have a chance to publish once every second depending on how heavy the bus schedule is, this communication relationship may not help you. I think what you really want is time-stamping on the alarms to be done in the device so that you know when they occurred regardless of when they were communicated.

3. The FoundationT Fieldbus protocol supports time stamping of alerts (collective name for alarms and events) in the devices. I suppose that DeviceNet/ControNet devices may have a similar capability. However, in FoundationT Fieldbus the time-stamped alerts are communicated using the "Report Distribution" communication relationship, I think the DeviceNet/ControNet equivalent is called report by exception.

If you want to know more about FoundationT Fieldbus (as well as Profibus-PA and HART, but not DeviceNet/ControNet) you may wish to take a look at the book "Fieldbuses for Process Control: Engineering, Operation, and Maintenance" (buy online in hardcopy or download immediately in softcopy): http://www.isa.org/fieldbuses

The "under the hood" stuff is in chapter 11, the other chapters are more day-to-day technical information and tips.

If you can't buy the book now, you can download chapter 1 (overview) for free in softcopy form. It's free, but you must register an account. If your email does not support this hyperlink feature correctly, please copy the entire link and paste it into your Internet browser. Mind the line wrap, make sure to get the complete path all the way to the 4585:
http://www.isa.org/Template.cfm?Sec...=/Ecommerce/ProductDisplay.cfm&ProductID=4585

Jonas Berge
SMAR
===========
[email protected]
www.smar.com
Learn fieldbus at your own pace: www.isa.org/fieldbuses
 
M

Mike Chivers

I have done time-stamping in a Modicon Quantum PLC before (using the EARS loadable) which was effectively just a cyclic buffer with a time, event number and event state in each register. That was straightforward but we had to write custom C code to get this into the SCADA alarms in a seamless way. The handshaking was also horrendous to ensure that the multiple SCADA machines all got only one copy of each alarm.

I guess I was wondering if anyone had seen a "nice and done for you" solution in the PLC market that handled this. I was thinking along the lines of a protocol server effectively built into the PLC. There are a number of protocols out there now (DNP, OPC, Suitelink, etc) that support time-stamped events, and many of the SCADA packages support the feature (eg Wonderware).
 
M

Mike O'Connor

You may want to consider a SIXNET Linux-based programmable controller. It basically has all capabilities of a PLC plus the functionality of a process controller. It handles datalogging and timestamping very well and can transfer data as a client on a periodic basis or when there is an alarm. SIXNET also offers a datalog server that runs in the PC along side your HMI. It accepts the logged data from the remote controllers and saves the data to a CSV file (or other formats) to be read into your HMI.

For details on SIXNET advanced datalogging and reporting please go to:
http://www.sixnetio.com/html_files/products_and_groups/datalogging.htm
or contact us at +1 (518) 877-5173.

Regards,
Mike O.
SIXNET Product Manager
[email protected]
 
B

Bob Peterson

I have had to do similar things to get time stamps out of PLCs before, but for the most part its a non issue to me because of the fact that usually I have not had a problem with allowing the SCADA system to time stamp it, because usually things in my world are slow enough that I don't have to worry about the exact millisecond something tripped.

Trying to get this kind of data from a general purpose controller is not trivial, but it can be done, but if you need it, better to get it in some format that is already proven functional.

I know a guy that did this in a slc500 once. he ended up writing some vba in rsview to get the time stamp data he needed that he generated in his plc. Not real clean, but functional. Not ideal if you had hundreds of them either, but for a few dozen events that he had to look at it was adequate.
 
M

marc sinclair

> Trying to get this kind of data from a general purpose controller is not trivial,

I use s7-200, one of the cheapest general purpose PLCs, time stamping of errors and faults (alarms) is indeed trivial

on alarm >

Add error code to table >

read RTC (real time clock) >

Add time to table >

Once it is in a table it can be read by a PROFIBUS master transferred to another PLC in a network, or using FTP to a pc file, emailed, SMSed, read by an HMI, read via a browser, sent serially, or printed directly
 
Thread starter Similar threads Forum Replies Date
A Networking 4
A Power Generation 4
C Sensors & Calibration 0
Top