By Jeremy Pollard
I will be a presenter at a SCADA conference in Bogota, Colombia, in August. SCADA and HMI are different, but then they're not.
I thought back to 1984 when I was at Rockwell Automation creating some project screens for a client sales presentation on an A-B Advisor embedded graphics system.
This device was a CPM-based SCADA system that created screen displays using object-like symbols and used small CRT display units for interfacing. A keyboard was the main interface for the operator with custom inserts for key definition. Plug-in cards were used for everything.
The development system was intense—a lot of code generation, driver configuration and object hoop-jumping. There also was a T30 operator/HMI terminal, which had a development system embedded in the unit. I don't think a touchscreen was available in the first few product iterations, but there were keypads on the unit faces so the developer could assign key presses to functions.
The screen components were not complex, but effective. There were color screens, as well as grayscale. It was a fully embedded SCADA system but was called an HMI.
The only portion of the SCADA component that wasn't available was the data acquisition part since there was no way to offload the data the terminal acquired, except through a serial port, but that normally had a printer attached. As I remember it, the Advisor system wasn't much better.
We've traversed so much technology since then. In 25 years, we have jumped orders of magnitude forward. Most “kids” don't know what CPM is, let alone an 8-in. floppy drive.
What's different, and what hasn't changed? Well, everything and nothing. What has remained the same are applications these devices interface with. I'm sure there are 30-year-old plywood presses with modern industrial computer interfaces running Windows-based software that we only dreamed about when the process was first installed using T30s and Advisor systems.
What's different is methodology—development software, options for development and runtime platforms, connectivity, protocols and transmission methods and tons of third-party support using such standards as ActiveX, .NET, Java, AJAX, XML and HTTP.
The availability of vital operating information in real time, data historians, KPIs and data-mining extensions make the modern-day differences between SCADA and HMI systems very blurry.
Machine control interfaces are connected to the controlling PLCs and PACs, and are connected to the plant-wide information highway, just as SCADA systems are. One of the more innovative products that blur the lines is embedded touchscreen terminals from Invensys/Wonderware. Wonderware is SCADA, but it also is HMI. It's the same development system with multiple targets. InduSoft is another.
Many new technologies are a hit with users and OEMs alike. A recent poll reported that most companies will use the controller vendor's HMI offering, if available. Once upon a time there were many third-party HMI developers. They got purchased by the big boys, so there are very few left.
The big third-party camp these days is in OPC servers, which is very odd.
With this development, there isn't a device on the planet that can't be connected and monitored by any HMI/SCADA system. Coupled with that, proprietary networks are all but gone. Ethernet wins that battle, wired or not. So all protocols, still somewhat proprietary, propagate over a connectivity standard. Who knew?
So where are we now? Which way do things migrate? My next few columns will reveal all. Web-based clients, licensing issues, Visual Basic, C#/F#, scripting and "server-based everything" all have their pros and cons.
For instance, anyone who would use a fixed HMI with embedded firmware for development, in my opinion, is crazy. A touchscreen interface with Embedded XP or Linux and a true development platform has to be on your radar. And I'll tell you why next time.Â
