The Use of Linux in an Embedded System

One company's solution to a customer problem using Linux and open-source software.

Interface Between the Control Program and the
Database

This was one area where we had just enough experience to be
dangerous. We knew it could be done and this was one potential hot
spot. In evaluating various database packages, we looked at the
licensing terms and the availability of support for embedded and
web applications. It seemed as though many of the databases
available for Linux took care of the last two requirements. The
licensing aspect was more varied in that several of the
better-known packages provided for a single user or non-commercial
use at no fee. Since we would be installing this on many systems
and for commercial purposes, licensing was an issue we didn't want
to overlook. When we pursued it, we found some of the license fees
were higher than the going rate for MS Access. That alone
eliminated some of the choices. We eventually settled on using
PostgreSQL. Besides the very liberal copyright, we were strongly
influenced by the availability of high-quality documentation.
Having the opportunity to review the manuals before even committing
to downloading the code was enough to reassure us this was a good
path to follow.

Once the database was chosen, we had to get down to the
details of implementation. The first part was to define the schema.
Having had some experience with SQL previously, I found that
psql was easily adapted. Knowing
that the schema was likely to change as the project evolved, I
wrote a few scripts to define all the tables and fill in default
values. This took care of setting up the database. The next step
was to define the interface to the control program. On the same
premise that the database schema would change, I set up the
interface as a separate module with subroutines to read selected
data into working buffers. With the exception of the log table, all
of the tables were read only for this function. Thus, there is a
subroutine to read a selected record from each of the tables. The
only other exception to this approach is that when the system first
came up, a way was needed to determine just how many doors were
implemented. This merely took a set of subroutines that would open
the table, return the next entry in the table on each call and then
close the table. This allowed the program to scan all possible
entries to set up the communications links and other structures.
All the functionality I needed was provided by the lilbpq library
included with the distribution. It turned out to be easier than I
had first expected.

Interface Between the Database and the User
Interface

This aspect of the project is a bit more complicated because
of the number of different packages involved. If you recall from
the outset, the idea was to use the web browser as the user
interface. This meant we needed to provide a web server on our end
of the link. For anyone in Linux, the choice of Apache is a
no-brainer. However, we needed to link it up to our database in
some way. Because of the availability of Perl expertise, we chose
to go that route. In order to provide a complete package, we also
needed to include other modules. For the interface to the database,
we added ApacheDBI, DBD for Postgres and the Perl DBI package. To
support all we needed in Apache, we added Digest, HTML-Parser,
MIME-Base64, URI, Apache-SSI, libnet, libwww-perl, and mod-perl.
Quite a conglomeration of packages, but when installed correctly,
it all worked very well.

The design of the user interface was broken into two primary
sections. The first was a set of routines that formats the data for
display on the user's screen. The second is a main routine that
accepts input from the user and processes it. Generally, that
processing consists of updating the database and passing control to
an appropriate routine to display a new set of data for the user.
On top of all this, Javascript was used at the browser level to
perform validity checking before passing parameters back to the
main routine. Because of the amount of data being passed back and
forth between the browser and the system, we kept things fairly
simple. The only graphic we used was an identifying logo.

In general, the user is allowed to select a specific table
from a top-level menu. Once a table is selected, the user is
allowed to list the current table, look up an existing entry,
modify an entry, and of course, add or delete entries. Since the
data in the various tables may be somewhat sensitive and the people
defining a door have different needs from those defining job codes,
we added one other table to the system. The security table has
nothing to do with normal operation of the system, but instead
determines who may see what tables. It worked out nicely and it
also gave us a means of allowing only certain users to have access
to the system.