When Considering Controllers… Do Operating Systems Matter?

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.

By Renee Robbins and Barb Axelson, Control Engineering April 1, 2009

Sidebars: Linux in automation? Not so much…yet

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%

Author Information

Renee Robbins is senior editor of Control Engineering. Additional reporting conducted by Barbara Axelson.

Linux in automation? Not so much…yet

Linux has been around for 15 years, and has achieved successful penetration into many IT market segments. It is predominantly known for its use in servers, where it is supported by all the major IT players. But it has never done well in computer-based industrial controls. Such open source initiatives have their supporters and detractors

“In the automation industry there has been talk for a lot of years regarding offering PLC and PAC controllers with an operating system, namely Linux, that will allow the OEM/machine builder (or even the end user) to develop their control code in a “higher-level” language such as C++ or Visual Basic,” says Arun Sinha, business development director for Opto 22. “In this scenario, the operating system is not kept behind the scenes, but is one that supports the needs of those open, higher level languages without sacrificing reliability. Opto currently offers this kind of Linux-based I/O processor/controller and a newer, more powerful version is in the works,” he adds.

Michael Babb, editor in chief of Control Engineering Europe says Linux hasn’t done well in automation “because it requires the intense cooperation among vendors to make it work.” That is starting to happen, he says, at least in Europe.

Babb reports that, in Germany, open source began to take hold with the formation two years ago of the Open Source Automation Development Lab (OSADL). Dr. Carsten Emde, the group’s manager, said OSADL is modeled on the OSDL (Open Source Development Labs), which merged with the Free Standards Group to form the Linux Foundation (LF). What the OSDL/LF has done for Linux in general, the OSADL aims to do for Linux in automation.

From the user perspective, system integrator Joe Simcik of I&C Design LLC says that, in his experience, “end users may or more likely may not be versed on Linux. At this point in time, it is used by the technically savvy, large system market.” Linux’s optional, customizable GUIs (compared to Windows’ integral GUI) greatly increase the speed, efficiency, and reliability for a server, he adds.

The downside of Linux, according to Simcik: Users “routinely (even though we wish they wouldn’t) use these PCs for other tasks. Also, due to the open, customizable user interface, a new user might walk up to several different Linux-based PCs and see something different.”

Prasanth Gopalakrishnan of Kalki Communication Technologies says, “We are implementing more controllers for our customers with Linux, and we see that most of the SOC/processors are coming with support for Linux/WinCE, and their memory-addressing capabilities and processing capabilities are expanding fast. For any new design, controller designers are more inclined to choose this, for they have greater flexibility and cost under control, and the performance issues are not a serious concern with the higher speed of the processor, bus, cache, etc.”

Machine builder Mauro Arigossi of Alfamation Inc. says “playing with Windows and Linux is fun, but not everybody has the process, knowledge, consciousness in place, or simply the time to properly manage them.” He contends Linux can be a plus “when well-supported by associated functionalities to manage system applications, development and deployment, and a safe drive certification for application development engineers.”

One last piece of advice when using open systems for controls, says Arigossi: “I’d suggest never referring to these systems as a computer or a PC, nor using the magic words of ‘Windows/Linux.’ This attracts IT policy guys as antibodies toward a bacteria.”