Linux for Embedded Systems
Figure 3 shows the top-level block diagram of the monitoring system. We are using the Slackware 3.0 distribution with XFree86 for graphics. The application programs are compiled with the GNU C compiler (version 2.7.2). In some parts of a different application, we also use Tcl/Tk for our graphical user interface (GUI).
Many parts of the software, especially the X11 graphics, were ported without any problems from our existing Unix applications (under SunOS 4.1). A large part of our labor was spent on file system issues, in order to make the system installable and robust.
Our design is based on the UMSDOS file system, which resides over an MS-DOS-compatible host file system, e.g., Microsoft Windows. The decision to use UMSDOS took into account the reality of the proliferation of pre-installed Windows systems. Although Windows will not normally be used after Linux is up and running, we prefer not to remove it completely or to give Linux its own disk partitions.
With UMSDOS, the whole Linux system looks like a single MS- DOS directory tree from the Windows side. This fact gives us the option of doing installation and some restricted file maintenance from Windows, using CD-ROM or floppies. However, we have found it faster and easier to boot Linux from floppy and stream the system to the hard disk through an Ethernet link. Network installation worked flawlessly both for desktop PCs, using a D-Link pocket adapter DL620, and for notebook PCs, using a Megahertz (US Robotics) PCMCIA network card.
The code we used to make the installation floppies, one each for the server (host) and the client (target) machines, is available by anonymous ftp at ftp://ftp.linuxjournal.com/pub/lj/listings/issue41/0133.tgz. Installation is almost completely automatic by starting the two networked PCs from floppy and answering a couple of questions about the X11 driver, display size etc. Because we have these floppies, the Linux file system with our applications can be “cloned” again and again from one Windows PC to the next.
Apart from installation, a major problem for our system is the crash recovery of the hard disk. Since we cannot guarantee orderly shutdowns, we have to deal with the cleanup after a “power failure”--like shutdown. We use the following techniques:
Writing to the disk is restricted; most parts are made read only, and there is no swap file.
At startup, the rc.local script runs the umssync program on the writable directories to repair possible inconsistencies.
Possible garbage from a previous run is removed automatically.
For emergency re-installation, a second clean copy of the full Linux system is maintained on the hard disk, and it is used to manually replace a damaged system.
In the future, we will use a RAM disk for the temporary files, and we hope to eventually fit the system into EPROMs.
We have installed the system both on notebook machines and on desktop computers. In case of the notebooks, the DSTN color display had a relatively narrow viewing angle, but it was usable.
The system was built into the group controller panel, and it has been tested under field conditions. We have also tested it at the research laboratory by connecting it to an elevator simulator that simulates a heavy load: 8 cars, 32 floors, all elevator cars moving constantly. All of this has proved to be a rather easy task for our system. There was no problem with either the serial interface, the graphics or the logging of the monitored data. Under the heaviest load conditions, we could log into the system and run other programs, even recompile the application, without any effect on performance. Response was instantaneous, and it was evident that this platform can handle much more demanding applications.
We have tested the power failure and recovery capabilities and checked that the system can withstand almost any abuse.
As a future development, we are considering a system with a boot/root file system in ROM and a read-only, mounted hard disk for the large applications and libraries. Since we want to put a normal Linux file system on the hard disk, we need to develop kernel patches that let the system boot from a small root file system, and switch parts of it (/bin, /lib, etc.) during initialization.
Eventually, we would like to extend our tests to industrial grade PC systems and check the usability of Linux for continuous operation under strict environmental conditions. This would open the way for moving more critical monitoring, security and control tasks to the Linux/PC platform.
|A Project to Guarantee Better Security for Open-Source Projects||Aug 27, 2015|
|Concerning Containers' Connections: on Docker Networking||Aug 26, 2015|
|My Network Go-Bag||Aug 24, 2015|
|Doing Astronomy with Python||Aug 19, 2015|
|Build a “Virtual SuperComputer” with Process Virtualization||Aug 18, 2015|
|Firefox Security Exploit Targets Linux Users and Web Developers||Aug 17, 2015|
- A Project to Guarantee Better Security for Open-Source Projects
- Tails above the Rest, Part III
- Problems with Ubuntu's Software Center and How Canonical Plans to Fix Them
- Concerning Containers' Connections: on Docker Networking
- Build a “Virtual SuperComputer” with Process Virtualization
- diff -u: What's New in Kernel Development
- Firefox Security Exploit Targets Linux Users and Web Developers
- August 2015 Issue of Linux Journal: Programming
- Three More Lessons
- LibreOffice 5.0 Looking Good and Shipping This Week