Linux-Based PLC for Industrial Control
The PuffinPLC Project is an effort to produce a Linux-based GNU Public Licensed Programmable Logic Controller (PLC). PLCs were developed in the 1960s to replace the complex electrical relay circuits widely used for machine control in industrial automation. Users program PLCs to define a series of actions that a machine will perform. The PLC works by reading input signals from devices such as sensors or switches and, depending on the value(s), turning outputs on or off.
In its simplest form, a PLC replaces relay logic. Instead of mechanical devices like interconnected relays or timers providing the logic for a machine or other device, the PLC is a single boxed device performing the same function. Because it is programmable and in essence a computer, it is more flexible, easier to change than physical relay wiring and a great deal smaller than the relay equivalent. It can also perform arithmetic and other functions, such as servo control and analog measurement.
Traditional PLC programming resembles a relay diagram, and for simple diagrams it has the same meaning. However, there are some differences. For example, the diagram works repeatedly from top to bottom rather than all at once (see Figure 1). Additionally, the external-world contacts of relays don't open or close until the bottom of the diagram, input relays change only at the top of the diagram, and there are some restrictions on the connections allowed. This heritage of relays with coils has led the internal state variables of modern PLCs to be commonly know simply as ``coils''.
Over time, PLCs have introduced new programming methods that have become dominant in the industry. These fall into two categories: text-based programs and graphical stateflow diagrams. There are many proprietary and nonproprietary standards of varying complexity and functionality for each category. PLCs are usually programmed off-line, using tools running on DOS or Windows. The text-based programs or diagrams are compiled to an intermediate language that is downloaded to the PLC and interpreted.
Although simply replacing relays would be enough to explain the success and popularity of the PLC, a much greater advantage arises from the concept of buses: several PLCs or parts of PLCs on a single cable, communicating, cooperating and reporting to a central control room. This effectively integrates the factory floor into a seamless whole, linked by a barely visible electronic thread.
Since manufacturers have taken different approaches to PLC development, the result is a veritable Tower of Babel. Dozens of product lines provide essentially identical functionality and most are incompatible and non-interoperable. Customers have a choice of vendors but are then locked into that vendor's proprietary solutions. No good open alternatives are available. What Linux is doing for the highly proprietary embedded systems market is what we propose to do for automation with the PuffinPLC.
The PuffinPLC is an interesting study as an embedded controller. Like the PLCs it will replace, it is much more general than most embedded projects. PLCs tend to be very expensive. The PuffinPLC running on an off-the-shelf PC will be more than cost-competitive. Recently, PC-based controllers have emerged, typically running a real-time executive with Windows as a low priority task. If this sounds a lot like what RTAI or RealTime Linux does, that's where we are heading.
Providing a platform for sharing and code reuse should make it possible to raise the productivity of solution providers by at least an order of magnitude, eliminating the enormous waste of maintaining hundreds of parallel solutions. This will allow integrators, consultants and in-house teams to concentrate on their core competencies. A free, open solution will also benefit educators who teach the use of controllers and how they work.
Although the PuffinPLC is intended to emulate a standard PLC, it has a very different architecture. This is partly to take advantage of the fact that it will be running over a full-fledged operating system (in this case Linux), but mostly because we want it to be highly modular to support multiple parties developing code simultaneously.
Unlike standard PLCs, the PuffinPLC does not necessarily run in an infinite loop that reads the inputs, executes the logic and updates the outputs. The PuffinPLC is composed of autonomous modules that, by default, will execute in separate processes. Each of these modules is free to decide whether or not to execute in a standard loop. Communication among the modules is made through a common PuffinPLC library of routines (see Figure 2), written in C and with C header files available. These routines access two common memory areas that together harness the PLC's state and synchronize using semaphores.
Despite this, however, the standard PLC model permeates the structure: the PuffinPLC library offers PLC-like semantics for the modules that wish to use them. For example, inputs can only change at the beginning of the logic, and outputs are only written at the end of the logic. This means a user's PLC skills can easily be transferred to the PuffinPLC.
Each module is dedicated to a specific function. Some handle physical I/O, reading inputs from I/O boards and copying their states to the PuffinPLC internal coils, or writing the state of other PuffinPLC internal coils to physical outputs. Some modules are dedicated to executing the program logic, and others may be dedicated to communicating with other PLCs. All modules run asynchronously by default but may be synchronized using the PuffinPLC library.
With a modular architecture, contributors can write modules that implement a specific communication protocol, interface to a specific vendor's I/O card or support a specific PLC programming language. End users will be able to pick and choose the modules they use.
A specific module can also have multiple instances running in a working environment. For example, a user wanting to run two digital filters at different sampling frequencies can create two processes of the same digital signal processing (DSP) module with different configurations. Each process will run under a different name, which is configured when the module is launched by a command-line parameter.
This architecture does not differentiate between modules executing logic and modules doing physical I/O. For this reason all the coils of the PuffinPLC are internal coils called plc points, and no output and input coils exist.
The mapping between plc points and physical I/O is left to the configuration of the I/O modules. Therefore, it is possible to have the same plc point mapped to more than one output. The opposite is not supported, however; it would not make sense to have the same plc point reflect two different inputs. For every plc point there is at most one module instance that can change that point (set/reset or set to a value).
For modules to run, the shared memory areas and the semaphore sets need to be set up. This is done by a utility called puffinplc, using the data stored in a configuration file (puffinplc.conf by default). This utility also launches the modules the configuration requires.
|September 2015 Issue of Linux Journal: HOW-TOs||Sep 01, 2015|
|September 2015 Video Preview||Sep 01, 2015|
|Using tshark to Watch and Inspect Network Traffic||Aug 31, 2015|
|Where's That Pesky Hidden Word?||Aug 28, 2015|
|A Project to Guarantee Better Security for Open-Source Projects||Aug 27, 2015|
|Concerning Containers' Connections: on Docker Networking||Aug 26, 2015|
- Optimization in GCC
- Using tshark to Watch and Inspect Network Traffic
- September 2015 Issue of Linux Journal: HOW-TOs
- Problems with Ubuntu's Software Center and How Canonical Plans to Fix Them
- Concerning Containers' Connections: on Docker Networking
- A Project to Guarantee Better Security for Open-Source Projects
- Where's That Pesky Hidden Word?
- Firefox Security Exploit Targets Linux Users and Web Developers
- My Network Go-Bag
- Doing Astronomy with Python