In the field of automation, much is made of the processors that drive the designs. Over my 35-plus years in the business, much has changed.
My earliest experiences with a programmable logic controller (PLC) were with a fixed I/O format commonly called a brick. I cut my teeth on a PLC that was programmed in ladder logic and was entered in using mnemonic code. Mnemonic code is an alpha-numeric programming language that converted ladder logic to Boolean commands. It might be called an ancestor of structured text languages like Basic, C++, HTML or Python.
Get your subscription to Control Design’s daily newsletter.
The brick PLC gave way to fixed rack designs where a solid frame called a chassis provided the backplane into which the processor and I/O modules were inserted. and modular PLCs followed.
Fixed memory transitioned into tag-based systems, and PLCs became programmable automation controllers (PACs). The processor and the I/O can reside in separate locations, joined by a network connection. The processor can be software-based and reside on a computer or server. The journey, started more than 45 years ago, is nothing short of amazing.
The interface
Often lost in the progression of the programmable controller is the equally amazing evolution of the human-machine interface (HMI).
When I first came into the industry in 1987, the HMI was still dominated by push buttons, selector switches and pilot lights for many applications. Often, these interactions would take place on a mimic board. This was literally a board where the machine or process was depicted pictorially, and then small lights were inserted through the board at the critical spots in the process to indicate the position or action of the various components.
Arrayed across the bottom of the board would be push buttons and selector switches that would allow for manual operation of the devices. There would also be a section to select automatic mode of operation and accompanying start and stop buttons to engage the whole process at once. For smaller machines or operations, a suitably sized junction box would be used to contain the buttons, selectors and pilot lights.
To enhance the experience for the operator, mimic boards and operator stations would often have a digital message display upon which pre-defined messages could be displayed. Due to the limitations of these displays, only alpha-numeric information could be displayed, and the earlier units had only one color for the text on the device. Sometimes the device could actually scroll the message horizontally for longer messages.
To program one of these units, the programmer would have to define the messages in an off-line programming application. There was a limit to how many messages could be stored in the device. To actuate the messages, the device required digital inputs configured in binary code for each message. To display multiple messages required additional programming in the PLC to manage the display time and cycle through each active message.
Text-based operator screens
Not long after my launch into the field of controls and automation, text-based operator screens began to appear. The units were alpha-numeric display only, so navigation to the various screens was made via a touchpad located around the perimeter of the display area.
Most vendors had a row of function keys defined across the bottom of the panel, below the display area and then an alpha-numeric, or sometimes just numeric, key pad off to the left or right of the display. Programming of the various displays was very basic and limited by the need to only use alpha-numeric characters.
To create interaction with the operator, the function keys were used to assign input parameters to which the operator could select the desired function key and then enter a value via the keypad. There was no way to display any sort of graphics at all.
About the same time, cathode-ray tube (CRT)-based operator stations began to appear in the industry. These devices were basically the same cathode-ray tube that formed the basis of a television set with an operating system that could be programmed to display some graphics that resembled the buttons, switches and lights of the operator station with the ability to also display text messages.
These early HMIs were monochrome—only one color—or, if you were lucky, four-color. The software was quite limited in that there were predefined grids on the visible screen where components could be defined. Due to the very low screen resolution of the day, the objects tended to be large in size, nearly as large as the physical devices of an operator station.
The greatest improvement was the graphical nature of the electronic HMI. Changes could be made to better organize and reflect the controlled machine or process. Multiple screens could be programmed, and buttons on the screen could be defined to navigate through the various screen pages.
These early graphical HMIs communicated with the PLC by exchanging blocks of data. The data, at its base element, was binary and resembled the same format as a remote rack of I/O modules. Over time, methods of communication changed, as PLC data formats changed from fixed blocks to tag-based. Now, the human-machine interface is efficient in the use of memory, keeping communications quick and responsive.
HMI vs. SCADA
As the technology behind the HMI evolved, a split happened in the application of the HMI to suit the two main focus groups—machines and processes. Machine applications tended to focus on replacing the physical buttons, switches and lights of a traditional control console, while process applications focused more on the graphical representation of monitoring and controlling industrial processes.
There were a handful of early players in supervisory control and data acquisition systems (SCADAs). An oversimplified description of HMI versus SCADA would be digital versus analog representation. This natural division in the application of graphical interfaces in the late 1980s would see a natural evolution of each technology on its own merits.
Hardware vendors had their own approach to graphical representation, and it was naturally tied to the PLC and communication platforms they chose as the basis for their product lines. Fortunately, not all vendors were tied to a particular platform, and this has helped the industry over the years by encouraging competition and provided a means to get graphical interfaces into applications that might not have been considered otherwise. A controls engineer can get a PLC with HMI for just a few hundred dollars and get a good quality solution.
Working in the industry as long as I have, I’ve had the fortune to work with most of the major automation brands. The most revealing aspect of this journey is learning that each brand has its star features, but, stripping away the look and feel that goes with the brand, you will find the same approach in the development of the application.
Create objects on the screen, and then map the object to a tag or tags in the PLC database.
This approach is the same, regardless of machine or process application. If you have enough time to really dig into the hardware and software, it’s amazing what you can come up with.
I came from an OEM background, and we never seemed to have enough time to do much more than make screens to control and monitor the application. As an end user with that OEM background, I now get to spend hours developing great screens and then creating a library of my work to use in future projects. It is well worth the time if you can commit to the effort.
A recent trend has brought the whole journey of the HMI full circle. Some of the major vendors are now blending the look and feel of a SCADA software development environment with the ease of development that has traditionally been the venue of the HMI development environment. There is a lot more going on behind the scenes of the development environment with automatic tag generation and the ability to create tags in either the HMI or PLC software development environment that are automatically created in the opposite device, as well.
The melding of HMI and SCADA
SCADA has long resided in the industrial PC world, while HMIs tend to be in the on-machine enclosed package. This trend to melding the two is likely the result of the migration toward soft PLCs and the software developers coming out of educational institutions with structured-text-based programming skills, rather than the traditional ladder-logic applications.
To a veteran controls and software developer, the blending of SCADA and traditional HMI development kicked me into a resistive frame of mind, but this evolution is good for the industry and puts a lot of power in the hands of the developer. I was asked to be a beta tester of the product from one vendor, and I have to admit I felt like a complete novice at the task until I got my head around the fact that it isn’t a traditional HMI.
I leaned back on some earlier experiences, and suddenly it all started to make sense. Evolution is good, and, if we are willing to embrace it, good things happen.
