As OEMs continue to move toward leaner design, operator interfaces have evolved into replacements such as automated panels for PLCs in many machine applications. So what are the differences between PLCs and automated panels, which are human machine interfaces (HMIs or control panels) combined with controls, and what are the advantages and disadvantages of each?
In the early days of automation, original equipment manufacturers (OEMs) shipped control systems with rack-mounted PLCs, pilot lights, gauges, and push buttons. Over the years, the vast majority of OEMs have simplified systems by going to operator interface (OI) panels rather than other panel-mount components. To reduce wiring costs and make it easier to ship equipment in modular sections, many OEMs have also moved to distributed IO. And, to further reduce the costs associated with reactive maintenance, many OEMs are also adding secure remote connectivity to access end-user networks so users can remotely modify programs and analyze equipment performance.
Typically, an OEM machine would use a programmable automation controller (PAC) with distributed IO, a touchscreen operator interface with data logging, and an industrial security router. The PAC, OI, and router each have their own processor, installation requirements, and unique software configuration. The processing power of these components far exceeds the needs of most applications, so the temptation to combine these components into a single device is overwhelming. But what are the tradeoffs?
Advantages of Automation Panels
Automation panels combine the functions of a programmable controller and operator interface into a single unit. They came on the market about 15 years ago. Many early units were simply OI panels with some local IO, ladder logic, and a flat database. Modern panels, such GE’s QuickPanel+, include the full IEC61131 programming languages (ladder, structured text, function block diagram, sequential function chart, and instruction list), as well as user-defined data structures and function blocks.
Automation panels, such as GE’s QuickPanel, reduce hardware costs by combining the controller, operator interface, and remote connectivity into one device.
It may be more accurate to describe these panels as PAC controllers with a built-in operator interface, rather than just an operator interface that performs control. In the case of the QuickPanel+, OEMs can buy a remote security software package from Secomea that lets OEMs securely connect to the panel over the internet using the customer’s network, eliminating the need for a separate security router. The advantages of this simplified architecture include cost savings, simplified maintenance, and improved performance.
Automation panels can also significantly reduce software development costs. Many automation suppliers tout the benefits of a shared database between the PAC and OI panel, but if these are separate devices, they still have separate databases at runtime. This means each time you add a variable, you need to download to both devices. If the controller and OI get out of sync, you end up with communication errors and possibly unexpected operation. Automation panels use a single database with a single development environment and a single library for reusable objects.
Hardware costs are also reduced. Combining the controller, operator interface, and remote connectivity into a single device means only one device to purchase, install, and configure. This saves money on both production time and on panel space.
Maintaining one device is less work than maintaining three, especially when you have shipped a system to an end user that may be hundreds or thousands of miles away. With an automation panel, you can back up the operator interface and logic program on a single memory card or USB stick. If the end user has separate files for the operator interface and controller and needs to restore one or both programs, they might load different revisions and end up with a non-working system. Having a single program to restore is easier and eliminates version compatibility issues.
A single device means a single point of connect. There is no need to connect to several ports to monitor or upgrade the system. This can be even more valuable when dealing with remote connectivity, especially if the PLC only has serial port programming. For example, QuickPanel+ with remote security lets OEMs easily access any remote sites by logging into a single server.
Improved OI Performance
It may sound counterintuitive, but combining the PLC and OI into one device can improve update times for the operator interface in many applications. This is because a main CPU task for a traditional operator interface is communicating with the controller. When today’s operators press a button on the OI screen, they expect an immediate response for the equipment and immediate feedback on the screen. The most common reason for delays in that response is the communication driver between the OI panel and the PLC. With an automation panel, this communication is much faster because it is internal to the device. There is no need to rely on serial or Ethernet communication links for updating operator screens.
It is important to note that this advantage may be overshadowed by overall performance requirements. For example, if the control system requirements consume the vast majority of CPU time, then the operator interface performance can suffer because it runs at a lower priority than the control. More on this later.
Perceived Disadvantages of Automation Panels
Programmable controllers have been an industry standard for decades. They have a strong reputation for reliability, performance, and real-time deterministic control. Anyone considering a move from traditional PLCs or PACs to automation panels should understand the tradeoffs. There are some significant misconceptions about the performance and reliability of automation panels in comparison to traditional PLCs. Before getting to the actual tradeoffs, we should examine these misconceptions.
Programmed logic controllers, such as GEW’s 90-70 PLCs, retain some advantages over automation including faster control-system performance, a high-degree of modularity, and well-suited for high-availability systems.
Is it PC Control?: In the mid-’90s, many were predicting that PC control would replace PLCs in the automation control market. While PC control works well in certain applications, it certainly has not taken over the market. The main issues with using PC control are:
- Determinism (required for repeatable IO updates).
- Security concerns requiring virus protection and OS patches.
- Long boot time.
- Registry errors (often caused by powering off without shutting down Windows).
- Moving parts in hard drives and fans.
Although PC control applications can take steps to overcome some of these concerns, the fact remains that Windows 7/XP/NT are not designed to be real-time operating systems.
Programmable controllers use real-time embedded operating systems such as VxWorks or QNX as well as many proprietary operating systems. When people first see an automation panel with a graphic screen and built-in control engine, they immediately think of PC control. But just like their PLC counterparts, the vast majority of automation panels run on embedded operation systems that have none of the issues listed above.
One of the most popular OS choices for automation panels is Windows CE. The Windows CE family has been used in real-time automation control for 15 years. With the introduction of Embedded Compact 7 in 2011, Microsoft dropped the Windows CE name and replaced it with “Embedded Compact.” This article will use the term “Windows CE” to refer to several vendors who use various generations of this OS including EC7.
The primary concern with traditional Windows is deterministic scan times. Windows performs numerous background tasks, so Windows users are all-too-familiar with waiting for responses while the computer does who-knows-what. If your control system had to wait some undetermined amount of time, the results could be disastrous. Like other embedded real-time operating systems, Windows CE achieves deterministic scan times for the controller by using thread prioritization and scheduled interrupts. The control function takes the highest priority. Windows CE has a small number of background tasks compared to a PC, but even these tasks have limited impact on control updates because they run at a lower priority. Similarly, time-consuming CPU tasks such as running a video or opening large files will have limited impact on the control scan time.
Real-Time Operating System: According to Samuel Phung, David Jones, and Thierry Joubert in Professional Windows Embedded Compact 7, “There are soft real-time and hard real-time systems. A soft real-time system can miss its bounded time response once in a while and still maintain a reasonable level of acceptable performance, such as when a Voice over IP device may delay or skip the delivery of voice packets and still provide acceptable service to the user. A hard real-time system cannot miss any of its bounded time responses. When a hard real-time system misses a bounded time response, it can cause catastrophic system failure.
“Imagine what happens when an automobile’s electronic brake system fails to engage in a timely manner while the automobile travels at a high speed and needs to make an urgent stop to avoid a collision. Compact 7 is a hard real-time OS that provides reliable core services to support embedded system design that demands low-latency, deterministic, real-time system performance. Compact 7 has the following features required by a real-time system: multithreaded and preemptive prioritized thread scheduling, priority inversion prevention using priority inheritance to dynamically adjust thread priorities, and predictable thread synchronization.”
Windows PCs are much more open than embedded platforms. They allow for numerous types of custom applications that can be developed and downloaded on several hardware variations. This leads to more overhead, longer boot times, security concerns, and frequent updates and patches.
Embedded platforms are compiled for specific hardware, and software must be written and compiled for specific implementations of the operating system. Windows CE platforms carry considerably less overhead and are not susceptible to Windows viruses. A QuickPanel+ on Embedded Compact7 can boot up and be fully functional in 30 seconds. This is faster than some PLCs on the market today. Windows CE platforms can be powered down at any time without going through the OS shutdown sequence required by Windows.
Some automation panels, including GE’s QuickPanel come in a variety of sizes. This lets companies tailor the panel to the application and work environment.
Reliability: Most programmable controllers have a well-earned reputation for reliability. Operator interface products have not historically had the same reputation. Resistive touchscreens wear out over time. The display backlight eventually fades or burns out. The screen becomes damaged due to exposure to the outside of the control panel. All of these issues have led many to conclude that these types of devices cannot be relied upon for control. But is that really the case?
None of the problems described above would interrupt the controller itself from running and updating the inputs and outputs. This is demonstrated in this YouTube video. In the video, an automated panel experiences catastrophic screen damage, but the panel is still controlling a red flashing light, showing that the control system continues to function in spite of screen damage. If a touchscreen or display is damaged or fails, the automation panel will eventually need to be replaced, but the control program will continue to run.
Mean Time Between Failure (MTBF) data is often used as a benchmark for reliability. MTBF values are significantly higher on PLCs than automation panels because of potential failures of the touchscreen and display. These failures are included in MTBF data because they indicate the device’s reliability as a whole, not just the control function. This is not an apples-to-apples comparison because a failure of these components will not shut down the control system. For an automation panel to operate as a controller, it needs to have only the power supply, CPU, and IO communications working. These boards use the same types of industrial grade components used in PLC systems and are just as reliable.
Control Languages: Since programmable controllers are dedicated to control, some engineers assume the programming languages are more sophisticated or user-friendly. In reality, the opposite is often true. Although some automation panels still have a ladder-only editor with flat databases, this is rapidly becoming the exception rather than the rule. Most automation panels support a full set of IEC languages, symbolic programming, user-defined data types, and user-defined function blocks. Of course, the same can be said of PAC controllers, but in many cases automation panels are competing against traditional PLCs with ladder logic and referenced-based addressing schemes that date back to the 1990s.
There are distinct, compelling advantages to using PLCs. They include faster control system performance, modularity, and the needs of high availability systems.
Many control applications’ performance requirements cannot be met by a single processor on an automation panel. Some panels, such as those with 1GHz CPU and 1G RAM, perform as well or better than many low- to mid-range PLCs even when handling operator interface requirements. But clearly a PAC controller with a 1GHz CPU is going to outperform an automation panel with a 1GHz CPU in terms of logic scan rate. If an application needs logic scans in the 10-msec range, this can be a delicate balancing act for an automation panel to meet the need while allowing adequate CPU resources for the operator interface functions. Larger systems may exceed the needs of a single CPU because of a specific combination of logic performance, graphics, data logging, and other tasks. In these applications, a separate PAC controller is the obvious choice.
Not every control system requires a dedicated panel-mounted operator interface. Some operate as blind nodes but many use a plant-wide SCADA system or a local PC for the operator interface requirements. Traditional PLCs and PAC controllers fit these systems very well. Many programmable controllers use separate removable modules for the CPU, power supply, local IO, and communications. If one of these components fails, it can quickly be replaced on an individual basis. Automation panels typically have the CPU, power supply, communications, and touchscreen sold as a single unit. If any of these components fail, you will have to get the entire panel replaced or repaired.
Control systems that typically need to run 24/7 without interruption typically use hot-standby, redundant CPUs with synchronized scans to avoid a system shutdown if a single component fails. Hot-standby control is not as common in automation panels. If the touchscreen or display fails, the system will continue to run. At that point, the operator interface functions could be handled through a remote web browser on a PC, or the system could automatically go into a controlled shutdown sequence. Either way, the panel would need to be replaced and would eventually require a system shutdown. With hot-standby CPUs on a PAC controller, the failed component can be replaced while the system continues to operate from the backup CPU, so typically no downtime is required.
Automation panels offer the same deterministic real-time control as traditional programmable controllers. Programmable controllers are a better fit for extremely fast scan times, very large IO counts, and high performance redundancy. For low- to mid-range applications that require a dedicated operator interface, automation panels provide a simplified architecture with easy remote connectivity options and lower total cost of ownership.