When Considering Controllers... Do Operating Systems Matter?
Controller vendors and system integrators weigh in on proprietary vs. open, including Microsoft Windows and Linux, and the importance of interfaces and programming tools.
Renee Robbins and Barb Axelson, Control Engineering -- Control Engineering, 4/1/2009
|
Traditionally, a programmable logic controller (PLC) was simply a black box that sported a proprietary operating system. The PLCs of 25 years ago were basically in the background, and most had to be programmed either on an attached keypad or with a hand-held unit that plugged into the system with proprietary programming methods. Today, there are many more choices of controllers and a push for open systems in information technology (IT) circles is affecting today's programmable automation controllers (PACs), PC-based control software, and embedded controllers. Some vendors promote a Microsoft Windows-based product as a benefit, while others downplay the underlying operating system and talk only about functions. Linux open systems and a handful of real-time operating systems also have their proponents. With such a variety of opinions, we wanted to know: Do operating systems (OSs) matter?
"The operating system is not nearly as important as the serviceability of the controller once it gets into the customer's hands; i.e., how easily someone can get under the hood and fix something or troubleshoot a problem," says system integrator Dan Walser with Applied Motion Systems. "Customers in certain industries often prefer a dedicated controller from a local distributor that does not require much in the way of training to swap out parts, press a spare CPU into production, or troubleshoot a logic problem. A Windows-based, open-architecture product that uses readily available parts and a simple software licensing system may be an excellent solution for a highly technical customer, yet the kiss of death for a less sophisticated customer."
As a system integrator in the packaging industry for more than 25 years, Stephen Turner of Flexicell Inc. sees two types of user thinking: "Those who want to keep their cost down by using whatever we recommend, and those who will pay extra to match their own standards. Typically, the ones that pay extra for their standard are the larger companies that have more access to capital funds. The smaller companies want to enjoy the benefit of automation, but want to keep the initial cost down so that their payback timeline is as short as possible."
As a system integrator, Turner doesn't think the operating system has much impact on his company's decision-making with regard to equipment. "We try to accommodate whatever the customer wants if they want something different than our standard, which is the Rockwell Automation line of products. If, in the future, we find that the Window or Linux operating systems offer better ways of standardizing our programming, and the cost comes down, then that might be a viable option for us as an internal standard.
"Looking forward, I can envision a time when Windows- or Linux-based machine control might be a very powerful tool," Turner adds. "At the current time, though, cost and efficiency are at the top of our list."
Arun Sinha, business development director for controller maker Opto 22, agrees that machine builder and systems integrator (SI) customers care far less about the OS of the controllers they choose, and far more about the stability and reliability of the controller as a whole. "The OS of the controller is mostly transparent," he says. "That machine builder or SI is using development/programming software to set up and configure the controller to perform, and they and/or the end-user customer are using HMI [human machine interface] software whenever they're looking to get a fix on how that controller is performing and how the equipment it's connected to is functioning."
Sinha says that proprietary vs. non-proprietary operating systems are important considerations when integrating a controller into an existing automation environment, or when enabling communication to other systems or databases. "But this is a secondary concern," he adds. "In most cases, for the machine builder, the OS of the controller needs to be an issue that they don't have to worry about because it's in place, it's reliable, and they don't have to worry about it. Remember, this is a controller that's embedded in a larger machine or, for the SI, it's one component of a larger automation system. Futzing with the OS is the last thing anyone wants to do."
Rockwell Automation Logix product manager Axel Rodriguez says his customers are more concerned about addressing application needs and reducing direct and indirect costs than about which system runs in the controller. He says Rockwell is committed to open standards and technologies, such as the use of standard unmodified Ethernet and Web server offerings, and "we are also committed to leaving key areas of the system closed so that customers do not have to worry about the risks associated with integrating disparate, untested, and short-life technologies at the core of their architecture."
Rodriguez adds that Rockwell Automation "could benefit from the smaller effort and cost of developing solutions over an off-the-shelf operating system, but we are convinced that most of our customers' applications can gain more from a well-planned and specifically designed industrial control system."
That isn't to say Windows-based controllers aren't well-planned, or that they don't have their place. Often, however, Windows is used when connectivity to enterprise systems is needed, or where the familiarity of a Windows interface is preferred. But someone still has to manage the complexity and rapid pace of change of non-proprietary operating systems, and that's often the controller vendor. So, from the user or integrator's perspective, it still doesn't matter what the operating system is.
"Our clients use 80% proprietary systems at the controller level, but everything above the controller is MS (Microsoft)-based," says system integrator Don Ulrich of Stone Technologies. "We don't care what OS is in a Siemens controller for instance—the customer goes back to the vendor. People are happy to have PLCs (especially for larger systems), happy to have GE, Schneider, etc. because the long-term maintainability is done by them."
It's clear that there is a tiered approach to automation systems that means any discussion of operating system depends on whether you're talking about embedded control at the machine level, for example, or application-level operations control. Steve Garbrecht, director of product marketing for HMI SCADA software vendor Wonderware, points out that the battle for the OS at the shop floor computer level in manufacturing has waged for many years and "it is safe to say that, for the large part, Microsoft rules today—although Linux has supporters." As for the controller, he says PLC vendors are starting to push as much of the traditional HMI SCADA and information management applications into their hardware as possible. "But what does the PLC programmer want? More Windows apps to stuff in, a proprietary box? Or is it more important that the controller do what it is supposed to do—provide 100% accurate, available control?"
Schneider Electric organizational development specialist R.F. Jordan says most controller vendors use proprietary operating systems to optimize their hardware for speed and efficiency and to differentiate products in the market. "Generally the OS is transparent to the programmer, who sees the programming environment that sits on top of the operating system. This environment (and instruction set—data objects and functions) is critical," he says.
The major hurdle for machine builders and system integrators," says Jordan, "is the inability to choose best-in-class products because of incompatible programming environments. Moving from one controller manufacturer to another could require a learning curve on the part of the programmer that would affect their competitiveness. Organizations like PLCopen have made tremendous strides in defining standards for the programming interface. Manufacturers of controllers that conform to the standard have a certain amount of portability among themselves." Flexicell's Turner says that over the last 15 to 20 years most PLCs have switched over to programming in a Windows environment on laptop or desktop computers. "The programs are then compiled and downloaded to the PLC. Being able to copy and paste, along with other features of Windows, decreased the amount of programming time required for larger programs. This, along with ladder logic, has made programming much easier," he says.
European standards coming?
Most of the PLCs used by integrator Adam Snyder of ControlFreek Inc. still have proprietary programming software, although they all have a Windows-style interface. "The software is proprietary, but it is still similar in functionality and layout across platforms," he says. Snyder sees different styles of programming coming over from Europe, but says "it will take a big change to implement many of the standards that are used outside of the U.S. Rest assured, changes are coming—especially as the world market grows and the U.S., hopefully, starts exporting more controller-based systems," he adds.
Integrator Don Kiser of Optimation Technology Inc. says programming environments "are still designed from the standpoint of PLCs. If you want to program an Allen-Bradley PLC you need to use Allen-Bradley's software; likewise with Siemens, Omron, etc. And their software only runs on a Windows machine.
"The only deviation I see is with Modicon," Kiser continues. "They have chosen to make their protocols public, and have allowed the public to develop their own tools. If you search for SCADA and Linux, you won't find anything that will talk to an Allen-Bradley PLC or Siemens PLC; however, you will find Modicon. I don't see much Linux in the way of controllers or operating systems unless it's for a very specialized application; 99% of the time, under the hood will be some flavor of Microsoft operating system.
Integrator James A. Campbell of Viewpoint Systems contends that "it should be clear from the fact that the majority of automation systems are using a real-time OS now that the operating system is a very important aspect of system design." Viewpoint has used Windows CE platforms, he says, and "although these devices are not strictly running a real-time OS, being stripped-down versions of desktop Windows, they do offer more repeatable performance than desktop Windows."
Campbell says many devices that are integrated into his systems are stand-alone controllers and are thus shielded from the OSs running on those devices. But, he says, "it is important to understand that PCs are perhaps only the more obvious devices running real-time OSs. The instrument and controller marketplace has been and will continue to move towards embedded, real-time controllers."
Integrator Michel A. Levesque of AIA Automation Inc. says almost all controllers (PLC or DCS) he works with use some type of real-time operating system like QNX. "We don't specify, nor do we look at what OS is used in the controllers. At best it would be idle curiosity more than anything."
The bottom line
Integrator Eric J. Milus of Kline Process Systems sums it up best: Most controllers today operate using a firmware instruction set, which is generally property of the controller vendor, he says. The vendor provides a programming interface to the controller that allows hardware OEMs, integrators, and end users to interface with the controller. These programming interfaces generally reside on computers that run Windows, Linux, Unix, or some other OS. A variety of other software can run on open OS platforms that can be configured to interface with plant floor controllers including SCADA, MES, batch, SPC, etc.
"OS is not usually the determining factor in product selection," Kline says. "It's more feature and functionality focused (and, of course, price). Five to ten years ago, we saw [vendors] touting OS compatibility. Today, most software supports major OS compatibility, so OS plays a minor role."
| Source: Control Engineering Product Research: PLCs, Sept. 2008 | |
| Ladder diagram | 91% |
| Function block | 52% |
| Structured text | 23% |
| C programming | 17% |
| Sequential function chart | 17% |
| Flow chart | 16% |
| Proprietary software | 15% |
| Instruction list | 15% |
View All Webcasts
