The Linux PLC: not a project--a movement

If you put your ear to the ground, you will hear the rumbling of a freight train heading toward the automation controls industry. Controls engineers, machine designers and builders, maintenance engineers, and machine operators are tired of being locked into expensive proprietary controls systems. The time and the technology are right for open controls to become a reality.

In the open-controls environment, designers and builders can devise systems using the pieces of the solution that suit them best from a variety of manufacturers, without being locked into just one supplier and one supplier's control strategy. With the current pace of technology advancement, proprietary strategies are often outdated and frequently designed to limit the choices that might lead to other suppliers.

Furthermore, if truly standard control software evolves, the end user's marketplace of available systems integrators would not be limited to the ones who happen to use the exact language that works on the end user's machines, and systems integrators would not have to become experts in several different languages. This is the problem that the International Electrotechnical Committee (IEC) standard 1131 claimed to solve. Unfortunately, IEC 1131 (a semistandardization of the existing practice of a number of major PLC vendors) offered no guarantee that a program written to the specification would interoperate between different vendors and machines. Now the standards group is working to move toward that capability. However, standardizing on existing vendor models still locks the industry into different variants of rather inefficient and obsolete forms of language, further entrenching the automation industry in its lag behind software and computing advances.

Control.com (www.control.com) is currently hosting and contributing to an exciting new project designing an open-source PLC: the PuffinPLC. As an open-source product, software code for this PLC will be freely available to users and may be modified by designers to meet the needs of different applications. Open source is a pathway to open controls, allowing developers to write applications, drivers, and interfaces so that different pieces of the system can interoperate. Though new in the automation industry, open source has a 20-year history in software.

The PuffinPLC development effort is focused on Linux. A lot of the attention on open source has been on Linux, which (though popular with the news media) is not really the crux of the question. Linux represents the most widely used and supported open-source operating system (OS). Even though others are also used, Linux has the largest user community and greatest breadth of support. But why move to an open operating system, and why a Linux-based operating system? Linux has good points and bad points. The good points include a long history of tools and software development techniques; it's one of the best software development environments in the world. One bad point is that Linux isn't actually a real-time system, although it now has a number of real-time extensions available. The other primary reason for choosing Linux is that it is open source. With a proprietary OS, if there is a bug in the kernel, you can't look at the kernel source code, let alone modify it. This places severe limitations on the developer's ability to solve problems. With an open OS, such as Linux, all the source code is available to view and fix problems. For both engineering and business reasons, it makes much more sense to build a system based on a platform that is not a black box. When many developers become involved in an open-source project, the result is commonly supported software, peer review, and broad testing in a wide variety of environments able to support substantially more flexible and reliable systems.

So Linux has a head start and is a good place to begin--but it's not actually the point. The PuffinPLC project will introduce the first Linux-based controller available to industry developers. How does this advance the industry toward open controls? Open source and open controls are a boon to the end user. However, most end users won't make direct use of it; most users in our industry work with relatively high-level tools and probably wouldn't want to code or even analyze at the system software level. But if there's one thing we've learned after decades of control work, it's that when you approach any given controls project, especially in the discrete manufacturing domain, you'd best do so with a very large toolbox. This is getting increasingly true over time. The greater degree of sophistication in automation today requires the use of a greater breadth of technology, and an individual application will, in a seemingly perverse fashion, require some random assortment of this very wide field of tools. If the tools are incompatible, significant amounts of engineering time are spent on their integration, which has become more and more of an inhibitor in doing automation work. Frequently, the bulk of troubleshooting time is involved in determining the compatibility or incompatibility between different systems.

The goal of an open-control paradigm, with open-source software as an important component, is to allow the proliferation of compatible tools. This will make it possible to draw upon a large variety of tools that were designed to interoperate with one another for any given application. An open-source controller will allow developers to produce drivers, for example, for many different communication protocols and I/O devices--all of which are compatible with that open-source software, and none of which are dependent on the resources of a single company. For the end user, this translates into a broad array of options for building systems using many different, previously incompatible components.

So how does an open-source project work? Open source means that the source code for a product is available to any developer who wishes to work on or with the project--but this isn't a free-for-all. There is a complex process involved that gives engineers working on the project lots of freedom and lots of exposure. All changes are reviewed and exposed to the scrutiny of the broader community, in effect a resource-rich and unlimited quality-control environment.

In the words of the Open Source Initiative (www.opensource.org), "We in the open-source community have learned that this rapid evolutionary process produces better software than the traditional closed model, in which only a very few programmers can see source and everybody else must blindly use an opaque block of bits."

In an open-source project, engineers write pieces of the project code. Additions, deletions, changes, and discussion about it are open to the public. The official code itself is stored in a public repository on the Internet. Engineers can check out code (download it), modify it, and redistribute both their modifications and the original code freely. They can use it as the underlying base for their own internal projects. Though they can also base other products upon it, the open-source license used may or may not require that these other products also be open source.

As described so far, open source is of interest to engineers rather than end users. There are great end user benefits to mature open-source products in terms of quality, choice, cost-effectiveness, and control.

For open-source code to become part of the official project, it must pass muster with the community and with the person who acts as the "steward" of the repository (e.g., in the Linux community, this is Linus Torvalds). Thus the code is freely available to the community as a whole, but the quality of the official release is maintained by volunteer stewards. If the stewards don't do their job well, someone else can offer and maintain an alternative version. This "forking" of the code is an important right whose use is reserved for only the most severe problems, because it has the potential of causing painful disruption to the community. This distinction between community freedoms and limited stewardship is critical to understanding how open-source projects work and succeed in producing high-quality software products.

So if you or your company are interested in working on an open-source automation project, such as the PuffinPLC, these are the steps you would take and this is how the work would unfold:

• homework, reading associated documents, reviewing the parts of the source you think you need to modify. Above all, lurk on the appropriate forums/mailing lists to see what's going on. Some projects may require that you join to get access to these lists; many or most do not.


• Decide what you want to do.


• Ask about what you want to do. This is important for a couple of reasons: Someone else might already be doing it; there may be problems you haven't thought of; other issues may exist.


• Get the appropriate version of the code (download it from the repository), and develop your initial code or modifications. If you're really hoping to get your work included in future official versions, the appropriate version to download is probably the current development one.


• Test your initial version.


• Post the changes somewhere and announce them to the other developers and potential testers.


• Loop back to step 4 several times, learning from and responding to colleague comments, suggestions, or code changes. Your project should keep getting better as you do this. If you have something stable and useful (usually as measured by others), you can now try to make it part of the official project code or use it and continue to distribute it independently. This is a common long-term path for add-ons in many projects.

But ultimately, how does open source move the industry closer to open control? Developers working on an open-source project, such as the PuffinPLC, are making open-controls software available. As it is used and tested, it becomes more robust and begins to evolve into a standard platform for which drivers, interfaces, and software controls components are written. As these tools become available, developers and designers have growing options available for building systems with best-in-breed components. Further, since such code is usually written to be highly portable, many operating platform options also become available, making it possible to choose the best hardware and software possible for any given task.

The PuffinPLC project is just getting started. Though little code of interest to an automation user exists in the project today, this is a great opportunity to make a significant contribution to the future of open-source automation control! Come to puffinplc.org to look around and join the community.