Linux in Embedded Industrial Applications: A Case Study
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.
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.
Support from vendors may be more difficult.