Linux for Embedded Systems

A company in Japan is using Linux for embedded systems in vertical transportation equipment such as elevators.

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:

The lifetime of the product is very long, on the
order of 20 years or more.

Safety and availability of elevator service is a
deciding factor for the users, especially for medium to high-rise
buildings.

Continuous service and maintenance during the full
life cycle is vital; usually, it is even required by law.

To meet the requirements of long term,
disruption-free service and maintainability for embedded computers,
we have recently started to investigate the possibility of using
the freely available Linux OS and the GNU utilities.

The Target: Elevator Monitoring
Equipment

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).

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.)

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:

A custom graphic board with custom graphics
software

Control software common with our
sequence-controller, CPU board

Serial interface with our proprietary protocol to
communicate with the group controller

A multiscan VGA display (the only commercial
part)

These components were chosen to give us the following
advantages:

Stand-alone operation in the elevator, machine-room
environment

Real-time response

Long-term supply and maintenance

Low cost

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.

Advantages and Problems of Using Linux for
Embedded Systems

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:

The availability of the complete source tree of the
system, without any restrictions on use, distribution or revisions,
is vitally important to us. It can ensure that we will have some
way of maintaining our systems at a site 5, 10, 15, ... years from
now. If we wanted to guarantee the same with a commercial system,
it could easily become a nightmare. We could imagine the vendor in
2010 (if still in business) just staring at us with mouth agape,
when we ask them about bug fixes for their 1997 system. However,
when we have the source, maintenance becomes “difficult” instead
of “impossible”, just as with in-house, custom-made
systems.

An added bonus is the freedom from administration
of a royalty-based, license system for some proprietary OS; not to
mention the savings on the license fee.

We have been using Unix for system development for
many years. After some rather frustrating experiences with other
systems on the PC platform, our developers were quite eager to get
back to a Unix-like environment.

Even among Unix systems, Linux feels unique: it is
light, fast, runs on almost any platform, contains the latest
version of all free software and is now so visible that even
non-computer people are starting to talk about it. It is a good
feeling to be back in the mainstream again.

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.

Ideally, we would like to use a ROM-based system,
such as the one described in the article “Booting Linux from
EPROM” by D. Bennett, Linux Journal, January,
1997. In our case, however, we needed X11, Tcl/Tk, libraries,
fonts, etc., so we were forced to use a hard disk-based system.
This means that we have to think about disk-buffer flushing,
cleanup and recovery after messy shutdowns, etc.

Linux is not a “hard” real-time system as it
stands, although people are already working on real-time patches.
(See “Introducing Real-Time Linux”, M. Barabanov and V. Yodaiken,
Linux Journal, February 1997.) For our current
application, this was not directly a problem, but we would need
guaranteed response time if we wanted Linux to control an elevator
car.

Installation must be made foolproof, especially for
re-installation or upgrades. We have found that our customized
procedure works, but it still needs to be improved.