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.
The Gory Details

In this project we needed two non-standard devices, i.e., the Flash EPROM disk and the RS-485 serial interface. This didn't cause any problem: the Flash EPROM disk was used as a standard DOS formatted device and the serial interface replaces the COM ports and is managed by the standard serial driver.

Software Architecture

The protocol converter gateway software has a very simple structure. It consists of two independent processes: a data swallower and a Modbus server. The data swallower receives printing lines from the serial port, analyzes the strings, extracts relevant data and writes the values into a shared memory buffer. The Modbus server receives queries from the SCADA system according to the Modbus protocol specification and sends back the requested values, reading them from the shared memory buffer.

Two interactive programs have been added for debugging purposes: a memory dumper which prints out values read from the shared memory buffer, and a program to write values into the shared memory. Both programs can, obviously, run concurrently with the gateway processes.

All the code is written in C and the shared memory management was implemented by using the standard System V interprocess communication API which allows the creation and management of shared memory segments and provides semaphores for synchronizing the access to them.

Due to the very simple structure of the problem, synchronization was easily implemented by locking access to the entire shared buffer when doing a memory access. This simple-minded approach is quite suitable in this case because all the accesses to memory are performed in chunks and the low speed of the I/O operations, with respect to memory accesses, ensures that any process will wait for a memory lock release for relatively short times.

As a tool for the constant verification of the proper functioning of the gateway, a location of the shared-memory buffer has been reserved for a counter which is incremented anytime the data swallower process ends a reading cycle. The SCADA system periodically reads the variable and may thus raise an alarm if the variable is not incremented after a given period of time.

System Configuration

Following directions found in the Linux BootDisk-HOWTO, a small Linux system was built, starting from a standard Red Hat 6.1 installation. This is actually a trial-and-error process in that one has to find out exactly which files are needed for one's purposes.

Even though our Flash EPROM disk provided a comfortable 8MB of disk space, all the software must be transferred onto the target computer by floppy disks, thus it is desirable that the resulting system is as small as possible.

The tailored system includes the kernel, a number of standard Linux commands (we were fairly prodigal in adding commands: better to have all the needed tools at hand when doing maintenance in the future) and all the related libraries. It also includes the loadable modules which are needed to manage DOS format volumes. This may be useful to mount and access either DOS format floppy disks or the Flash EPROM disk.

Needless to say, the four programs developed for the gateway, plus a few ASCII configuration files used at startup by the two running processes, were also included.

Due to the Linux bootstrap procedure requirements, the above components were stored into two files: the compressed kernel image (450KB) and the compressed root image (2500KB). Just a tiny bit more than what would fit onto two floppy disks: we actually needed three floppies for the full distribution. In the BootDisk-HOWTO one can find a number of hints related to shrinking the size of the root image, but we felt satisfied with the size reached and did not want to work more on this aspect.

Bootstrapping the System

The Flash EPROM disk selected for the project (M-Systems DiskOnChip) is provided with a Linux driver and can be used as a Linux bootstrap disk. This can be done by including the DiskOnChip driver into the kernel but also requires some fiddling with a DiskOnChip configuration utility and a special version of LILO to make it bootstrappable.

After a few tests we preferred a different solution: DiskOnChip was configured as a plain DOS bootstrappable disk. This has the advantage of avoiding both rebuilding the Linux kernel and reconfiguring DiskOnChip (it is the device's shipping configuration) and moreover it was considered a more stable solution with respect to future releases of the device. The Linux image files are stored on the DOS file system and Linux is booted by the LOADLIN utility. This adds around 160KB of DOS files to the software.

The system's power-on sequence is thus:

  1. Boot DOS.

  2. Run LOADLIN from AUTOEXEC.BAT to boot Linux. The boot sequence creates the RAM disk containing the Linux file system and expands into it the compressed root image.

  3. Start the protocol converter processes.

The protocol converter processes are started at boot time because they are inserted into the inittab table. This also provides automatic restart in case of a crash of any of the two processes.

After booting, if the keyboard and display are connected, the usual Linux login prompt is displayed and a root login can be done. This allows us to perform maintenance operations and notably to launch Linux commands or use either of the two interactive monitoring programs described above. If needed (e.g., in order to make modifications to the configuration files without going through the entire process of making a new root image), the Flash EPROM disk can be mounted as a DOS volume.

______________________

White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState