|
|
|
|
|
|
|
|
A company in Japan is using Linux for embedded systems in vertical transportation equipment such as elevators.
by S. Markon and K. Sasaki
Fujitec is a global manufacturer and provider of a complete range of elevators, escalators and other vertical transportation equipment. Nearly all of our products use embedded computers in one form or other. To see the implications, a few features of the elevator business to note are:
We have in the past shipped several products using Linux. We will describe here only one of them--a monitoring display for group controllers (see Figure 1).
Figure 1. Controller Monitoring Display
Another application, a user-interface system for editing scrolling messages in elevator cars, is shown in Figure 2, but we do not have space to introduce it in detail. (Notice the Japanese characters--Linux works fine in Japan, too.)
Figure 2. Elevator User Interface
To put things into perspective, we need a few facts about elevators. If a building has more than 2 or 3 elevators, they are usually working in groups sharing the passenger traffic. A group of elevators is connected to a ``Supervisory Group Controller'', which shares the service of each elevator among users while attempting to give each user the illusion that he/she has a personal elevator.
The modern elevator group controller is rather sophisticated; it has to run difficult, optimal-scheduling algorithms in real time. The latest Fujitec models use neural networks for on-line learning and optimization. Without proper tools, the support personnel who perform installation and testing tasks wouldn't understand what is happening with the elevator group.
For maintenance checks, upgrades and occasional troubleshooting, the GSP (Group Supervisory Panel) has a graphical display showing the status of the elevators. This monitoring display was the target of our first Linux application.
Figure 1 shows the graphic screen of the monitor display. Information for each elevator, such as the present floor, traveling direction, door status, registered calls, etc. is indicated by graphic symbols. This screen design has evolved over several years, and it is now familiar to our technical and maintenance personnel.
We built most of the original monitoring display system with custom-designed components:
These components were chosen to give us the following advantages:
Even though we saw several problems with our custom-designed approach and wanted to move to an established, popular platform, until recently it was not feasible.
For the hardware, our first choice would have been the IBM- compatible PC, perhaps in the form of PC/104 cards. However, the dominant commercial OS (first DOS, then Windows), was unsuitable for many reasons. It is neither real-time capable nor reliable, and there is no chance that a particular release could have long-term support from its vendors.
Although there were many alternatives, such as the excellent Lynx OS, none of them satisfied all of our requirements, especially the long-term stability and availability criteria.
With the appearance of Linux, all this has changed.
Over the past few years, several engineers at Fujitec became familiar with Linux. Although we started it as a hobby, gradually the wider applicability of Linux became clear to us.
Our motivation for embracing Linux for product development has several roots:
However, not everything is rosy. Since Linux is essentially Unix, a few things had to be fixed before we could deploy it in an embedded controller.
Figure 3. Monitoring System Block Diagram
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.ssc.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:
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.
Linux is a viable and attractive platform for manufacturers who need a stable system that is ``theirs to keep'' for many years to come. Instead of developing in-house, custom-made systems at large cost or buying proprietary systems and leaving themselves at the mercy of the vendor, they can now choose Linux.
Linux, with the support of the Internet developer community and with guaranteed and affordable support from more and more commercial ventures, is seen by many as an ideal, software development platform. In our experience, it can also become an excellent deployment platform for computer-controlled hardware systems.
We are looking forward to the further expansion of our Linux business, and we hope the experience we gather will enable us to pay back a small part of our debt to the Linux community.
Sandor Markon graduated from the Technical University of Budapest and received a PhD in Electrical Engineering from Kyoto University. He has worked for Fujitec of Osaka, Japan since 1979 doing computer applications for elevator control. Present interests include neural networks, reinforcement learning, Internet programming with Java and industrial applications of free software. He can be reached via e-mail at markon@rd.fujitec.co.jp.
Kenji Sasaki graduated from Kyoto University, Faculty of Engineering. With Fujitec since 1976, he has been working mostly in control, systems development and communications. Present interests include Java, Linux and the Internet. He can be reached via e-mail at kjsasaki@rd.fujitec.co.jp.
