Linux in Embedded Industrial Applications: A Case Study

In order to allow the acquisition of diagnostic data from an existing industrial plant which was not designed for the purpose, a protocol converter gateway has been built by using an industrial PC running Linux.

A big turbocompressor in an oil
extraction plant is controlled by a 15-year-old Digital Control
System (DCS), which provides all the supervision functions, plus
the logging of significant events and data onto a printer. The
system has been running satisfactorily for years, but now the
management would like to integrate the machine into the global
plant SCADA system, where data from various machines are gathered
and processed in order to provide integrated management of the
entire plant.

The PLC-based architecture of the existing DCS is hardly
expandable and doesn't allow, from either the hardware or software
point of view, for the addition of the data transmission functions
which would be necessary for the project. A redesign of the DCS
system to add the required functionalities was considered an
excessively high-impact solution for the purpose.

The solution proposed was thus to add to the existing DCS a
sort of “protocol converter gateway”, i.e., a box which captures
the printer data stream, analyzes the lines of text to extract data
values and makes them available to the SCADA (see sidebar) system.
The latter will periodically issue data queries to receive the data
values from the gateway. For this part of the connection, the
standard protocol Modbus RTU was selected because of its simplicity
and because it was already widely used throughout the plant.

From the hardware point of view, what is needed is a box with
two serial ports: one to receive the printer data stream from the
DCS and the other to receive data queries from the SCADA system.
The box must run some program which decodes the printer data stream
and replies to the SCADA queries.

The main challenge in this kind of application is represented
by the particular environment: the plant is located in a
geographically remote area and the site has all the problems which
are usually found in industrial environments—dust, electrical
noise, wide ambient temperature ranges, and so on. Industrial PCs
are easily available on the market, but one must take into account
a few peculiarities which are usually not found in other
PCs:

There is no fan on the CPU. Spinning parts are the
weak points in a PC and the miniaturized CPU fan is particularly
unreliable with time. The main fan cannot be easily avoided, and is
accompanied by suitable filters. We can do without the CPU fan,
provided that the clock speed is reduced to limit the heat
dissipation needs.

There are no disks. The hard disk is substituted by
a solid state “Flash EPROM disk”. The floppy disk drive may be
included, but it will be used only for software uploading. This
means that the available disk space is very limited, usually not
more than 64MB, but in our case, just 8MB.

Standard RS-232 lines are not suitable for serial
data transmission in “noisy” environments. The more reliable
RS-485 standard is usually adopted.

The PC will usually run without keyboard or
display. They can be reconnected for maintenance needs.

As a result of some of the above constraints and due to
working conditions which are typical of embedded applications, the
software must also meet a number of requirements:

It must work with a small disk space.

It must require limited CPU power.

It must boot with no need of human
intervention.

It must restart smoothly after power off, both
programmed and due to failures.

It must cope with untrained personnel.

From the point of view of the software development, it was clear
that the software which analyzes the print stream had to be written
from scratch, while existing libraries could be used to write the
code needed to implement the Modbus protocol.

Choosing an Operating System

Why not a real-time O.S.? As it should
be clear by the description of the problem given, we are not
challenged by hard, real-time requirements. The limited speed of
the two I/O channels puts an upper limit to the data throughput and
no problem should arise from unpredictable delays in servicing the
two serial lines. This makes it possible to use a comfortable
standard O.S. and rules out any special purpose real-time operating
system as a cost-effective solution.

Why not DOS? The problem at hand is
essentially asynchronous in nature. The system must be able both to
swallow the data stream as produced by the DCS printer output and
to reply to queries from the SCADA system, two process which are
not synchronized in any way. DOS is thus clearly not a viable
solution. Although it has the advantage of being very lightweight
and having a small footprint, it would require quite a lot of
low-level programming to solve the problem.

Why not Windows 95/98/NT? Microsoft
Windows (especially Windows NT) is gaining consideration in
industrial applications due to the great number of third-party
packages and tools suited to any need, and because it is backed by
a major vendor. However, the hardware characteristics of the target
computer makes it challenging, if not impossible, to tailor a
version of any Windows brand to the limited file space and CPU
power available. Windows CE was not stable or reliable enough to be
worth consideration. Moreover, the peculiar (weak) multitasking
capabilities of Windows would likely make the programming of
concurrent applications slightly more difficult.

Why Linux? Managers are usually worried
when they have to make choices which are not “industrially
sound”. They will have no problems in justifying the choice of a
costly product provided that it is backed by a major vendor and has
a large installed base. This is not (yet) the case of Linux, so to
foster this kind of choice the technical arguments must be
particularly strong. In this case, I believe that the advantages
provided by Linux are superior to many objections.

The choice of Linux has many pros:

Linux can be tailored to any particular set of
needs down to the level of kernel configuration.

Documentation on how to tailor the system is
thorough and easily available.

Linux can run from a RAM disk, so the Flash EPROM
disk is used only to bootstrap. In this way the disk can even be
write-protected.

Development may be made in the same environment
where the target system will run.

It also obviously has some cons:

Finding drivers for non-standard devices may be
difficult or even impossible.