Linux serial programming

Linux for real-time PLC control? Slower is easier

Off-the-shelf computers provide an inexpensive platform for many of today's automation needs. GNU/Linux is an open-source operating system (OS) adaptable to these platforms and many computing problems.

The question arises: Why not use a combination of off-the-shelf computers and the Linux OS to run a programmable logic controller (PLC)?

When talking about a PLC, we typically refer to the entire controller-hardware components, systems, and application software. In general, the hardware consists of a CPU, some direct analog or digital I/0, network and fieldbus I/0, and at least one serial communications port.

Firmware guarantees that, once booted, the PLC loops eternally through a sequence of control instructions (its application software), which can be changed online or offline by a programming system to which it is connected. From a computing point of view, a traditional PLC is a single process running on the core computer hardware.

PLC Has 'Scan' Architecture

During the PLC's loop cycle, referred to as a "scan," the PLC carries out an input scan, executes the control and timer tasks in a roundrobin manner, and updates the output image.

Either at the end of such a scan or somewhere in between, the communications port is served for upload of data or download of PLC software. However, at no time during the scan do we see such external events as timer interrupt-driven schedulers launching tasks as independent computing entities.

The PLC is designed to run through the loop cycle as fast it can, and the worst-case loop time determines the response time of the system

Enter GNU/Linux, a portable operating system interface exchange (POSIX)compliant, Unixlike, general-purpose OS.

GNU/Linux runs on general-purpose computer hardware, such as off-the-shelf desktop systems, as well as on specialized computers such as CompactPCI or PC/104 systems, based on the same computer architecture. What all these computers have in common is that they utilize modem hardware techniques that push for throughput and average performance across a broad range of applications.

Techniques employed include fast, pipelined CPUs with many registers and interrupt facilities, several levels of cache for memory, buffers for all devices, and all kinds of buses such as industry standard architecture, peripheral component interconnect, and universal serial bus. Unfortunately, such a design, which seeks to be useful to nearly everyone, decreases the predictability of the system's behavior and has a tremendous impact on real-time and control processes.

GNU/Linux is a multiprocessing, multiuser OS. Similar to the underlying hardware, it is designed for maximum throughput and average performance. Several users and processes that compete simultaneously for resources are served on a fair scheduling policy.

To accomplish this task, the kernel of the GNU/Linux OS, Linux, uses such modem techniques as I/O buffering, virtual memory management, and other tricks to improve average performance. For example, Linux tries to regroup the hard disk block requests of several processes in a sequential order and, at a certain threshold, will deliver a series of disk blocks in one chunk. During this time, no other process can be executed.

The crucial question is: How can a PLC be implemented on Linux, given the opposite operating paradigms of the GNU/Linux OS and the PLC?

At the Open Control Laboratory of Control.com, we are working on such issues. We started with an open-source PLC run-time system called SmartPLC by Infoteam GmbH in Germany (www.infoteam.de). The runtime system was ported to Linux and implemented as a standard Linux process. It was combined with OpenPCS, a PLC programming environment that runs on Windows.

Under Windows, control software can be written in any International Electrotechnical Commission language, then compiled and downloaded to the run-time system using any network connection. The Linux process executing the run-time system then loops through an infinite PLC scan and carries out communication work every Nth cycle. Such an approach synthesizes both the off-the-shelf PC and the PLC paradigms.

Porting to Linux

Porting the run-time system was straightforward. Only system call-specific code had to be adapted from Windows C code to Linux and hence POSIX-compliant code. This involved file creation and handling as well as serial port communication system calls.

An issue arose addressing I/0 in the PLC World, such as %10.0 and %QO.O for input and outputs, respectively. Since in Unix everything is treated as a file, the analog I/0 is carried out by "ioctl" read and write functions to the corresponding driver. The input and output values are copied to and from the run-time system's process image and the input scan and the output update, respectively.

The most important resource to be offered to the run-time system is time-i.e., a reliable system call must provide a time stamp that can be used for all timer tasks of the PLC. Fortunately, Linux offers the "gettimeofday" system call, which gives time in microsecond (psec) resolution. This time data is retrieved from an internal kernel time data structure updated on each kernel timer tick in combination with the time stamp clock from the last timer interrupt on. But, we wondered, is this time stamp reliable, and what is its uncertainty?

Given Linux is a multiuser OS, the runtime system process could be preempted at any time, even within the gettimeofday system call. The control process will be rescheduled by the scheduler in an indeterminate amount of time, up to several seconds.

To test the predictability of such a PLC run-time system on Linux, we looked at a simple loop that gets only a time stamp and calculates the time difference between two consecutive gettimeofday system calls. This time difference should be constant and depend only on the execution speed. Nevertheless, there is a wide spectrum of uncertainty on time information with poor worst-case values. These values give an idea how long a Linux process carrying out control can be delayed and all its consequences on the system stability. For example, a "Is -R /" is executed in parallel on a Pentium 850:

This shows that, in most cases, the time uncertainty is less than 1 millisecond (msec), thus meeting the requirement for the Infoteam run-time system in 99.9998% of all cases. But if you look at the worst case of about 600 msec, this is poor performance.

A less portable version of this test uses inline assembler code to read the time stamp clock directly. Here the average performance results are better, but the worst case still remains poor:

Both examples show two time stamps are retrieved close to each other. But there is a second peak above 10 msec: the Linux scheduler time slice. Here, another process got rescheduled and ate up at least one such slice.

Here's what happened. The scheduler, the part of the Linux kernel that decides which process will be executed on which CPU next, offers three scheduling policies: SCHED_OTHER for all normal processes (the default time-sharing policy with static priority 0) and two real-time scheduling policies, SCHED_FIFO and SCHED_RR (with priorities higher than 0, up to 99). This means that as a normal user process, the PLC run-time system can be preempted for quite a long time.

One way to cope with this delay is to use real-time priority scheduling. And indeed, setting the priority to its maximum value and using the sched_setscheduler and sched-setpriority system calls helps quite a bit. Here is what these show:

What happens here is that no other process gets a chance to run. Only kernel threads and other kernel activities, such as reacting on interrupts, can prevent the runtime system from carrying out its control task:

To conclude, some will say that the standard GNU/Linux general-purpose OS is not appropriate for real-time control. Through our extensive testing, we have found that with some precautions, Linux can in fact be used, depending on the application's time constraints and uncertainty requirements.

For slow processes, Linux supports hard real time without any changes. For fast processes, some kernel changes are necessary, and as a last resort, the application can be built as a Linux kernel module.