I am working with a new customer to upgrade their old SCADA system. This is a water utility that does all of their pump & reservoir control within the SCADA software. They communicate via DNP3 to old proprietary RTUs.
I suggested that they move all of the pump & reservoir control logic into a master PLC, and use Ignition as an HMI, historian, reporting tool, etc. Now that the DNP3 driver is out with v7.8, I’m second guessing myself, wondering if there may be some advantage in moving all of the control logic to Ignition using gateway scripts, and abandoning the PLC idea.
Maybe take this with a grain of salt because I have practically no field experience, but… I always feel better when customers are doing control logic in PLC/hardware and using the software for visualization, history, reporting, etc…
+1 for a PLC as the master. Primary control algorithms belong in appropriate hardware. The ‘S’ in SCADA stands for ‘Supervisory’, after all.
Modern general purpose motherboards are infested with BIOS interrupts that create variable latency in any control system built on top of them. From the horror stories I’ve read, sometimes in the tens to hundreds of milliseconds.
In the old days (heh), operating systems often had drivers that would turn off interrupts for similar lengths of time (Windows IDE drivers were notorious). Supervisory controls can usually absorb those hiccups without user notice. Physical hardware, not so much.
If you must, choose systems and peripherals endorsed by Wind River (VxWorks) or by users of the various RTLinux platforms.
By comparison, PLC hardware is invariably built on a real-time kernel with response-time guarantees that can be applied to your user program. With hardware watchdogs to enforce it. Typically with no moving parts to fail. It’s not an accident that they usually last decades. Allen-Bradley publishes a forecast MTBF of 1,000,000+ hours for the -L6x controller family. I would expect similar ratings for competitive brands.