A vehicle-based embedded Linux system with nationwide wireless networking and GPS is a big task, right? Make it approachable by starting with the Earthlink SPARK system.

Industry experts predict that in-car computing, or telematics, will become a multibillion-dollar business in the next few years. Despite economic downturn conditions, this hypothesis may not be completely unrealistic, considering the recent growth: sixfold in a year for telematics equipment alone–from $60 million in 1999 to $380 million in 2000, according to Frost & Sullivan.

Independent software developers today essentially are excluded from the in-vehicle market. The closed systems being offered don't provide mechanisms for building or installing your own applications. Although many enterprising individuals have taken the home-brew approach, shoe-horning off-the-shelf PCs into the trunks of their cars, that solution is fraught with integration issues and ultimately isn't practical for most of us.

The EarthLink Simple Plug-and-Play Automotive Research Kit (SPARK) is a turn-key development system, based on Linux and open standards. It's designed to let developers easily test, evaluate and develop automotive applications using familiar technologies. The in-vehicle hardware (Figure 1) includes:

• Motorola Reflex wireless network interface
• 16MHz 32-bit Dragonball processor
• 2MB Flash memory
• 8MB RAM
• 12-channel GPS receiver
• vehicle I/O consisting of two optically isolated inputs, two relay outputs and one analog input
• RS-232 serial port
• Ethernet port

Figure 1. SPARK In-Vehicle Unit

The in-vehicle device runs µClinux, a special version of Linux that runs on MMU-less CPUs (see www.uclinux.org).

SPARK Linux Development Environment

Developing software for the in-vehicle device requires a development host. The EarthLink SPARK kit supports workstation PCs running any Linux distribution based on libc6. The PC must have a serial port and a LAN connection. The kit includes a set of tools for developing embedded Linux applications for the target in-vehicle platform. In particular, a modified version of the GNU compiler is supplied, along with customized libraries specifically intended for a small-footprint embedded environment. The kit also includes tools for installing your applications to Flash on the in-vehicle device.

Software must be downloaded to the in-vehicle device from the development host. The Ethernet port on the in-vehicle telematic device must be initialized by connecting to the DIAG serial port and logging in, using a communications program, such as minicom. The kit includes instructions for accomplishing this initial device configuration. The Ethernet port on the in-vehicle telematic device is a 10Base-T port (10Mb/sec), so the LAN must support 10Base-T Ethernet. Once the Ethernet port is configured, we're ready to start developing our telematics application software.

Passenger Heatstroke

According to the National SAFE KIDS Campaign, at least 120 children died as a result of overheated vehicles from 1996 to 2000. The Humane Society says the number of pets that die the same way is far greater. What's more, the research reveals that deaths frequently occur in weather most people would not characterize as particularly hot. Temperatures inside a parked car can soar rapidly above 100°F when the temperature outside is just 80°F.

A startling 10% of parents polled think it's okay to leave an unattended child in a locked car. Children seem to have a knack for getting into dangerous situations. An unattended parked car can appear as an ideal place for a child to play.

The Heatstroke Warning System

Our application uses the EarthLink SPARK kit as the basis for a heatstroke detection and warning system. We connect a motion sensor and a temperature sensor to the SPARK in-vehicle device inputs and produce a software application designed to monitor the sensors and take action if the vehicle becomes hot enough to put the occupants at risk.

SPARK Linux Application Development

Developing applications for the SPARK in-vehicle µClinux platform is similar to developing applications for desktop Linux systems. The kernel and libraries of the in-vehicle device are a subset of the typical full Linux system. The overall process is similar, using familiar tools like GNU make and the GNU compiler.

The SPARK kit includes a Makefile to create a working environment for a new project:

 mkdir heatwarn
 cd heatwarn
 cp /opt/AVL-sdkmaster/Makefile .
 make

This creates a basic working environment for our heatstroke warning system. The top-level Makefile in this default model is a sort of super-make. It first builds all applications from source code. Then it installs appropriate files into a ROM disk template directory and builds a ROM disk filesystem image. We cover these various actions in more detail in sections below. For now, let's focus on the src subdirectory that contains the source code to our applications.

In the src directory we will find a default Makefile to be used as a template. This Makefile is designed to build all applications in named subdirectories. The only such subdirectory in the default configuration is one called lcdoper, a sample application designed to interface to a Matrix Orbital serial LCD via the DIAG serial port. It is provided to demonstrate the use of the avlio library and as a basis for other applications. We won't need the lcdoper application for our heatstroke warning system, but we'll use it as a guide for our application.

For our heatstroke warning system application, we'll simply copy the model used by the standard Makefile to build and install the sample lcdoper application. We'll place our source code in a directory called heatwarn under the src directory, and we'll modify the default src Makefile to build our heatwarn application instead of the lcdoper application.

The Heatstroke Warning Application

The basic algorithm will be to take action if occupants are detected and if the temperature exceeds a threshold.

A library of C-callable functions is provided in the SPARK kit to access the AVLP protocol of the in-vehicle device. This protocol provides simple open-access to the in-vehicle device functions and I/O, alleviating the need for a complex low-level driver or kernel programming. Our application will use these C library functions to read the status of sensors, transmit wireless messages and to trigger the warning. Overall, this will make our application much smaller and simpler.

The first step is to connect to the AVLP service:

 if (avl_connect() != AVL_CONNECT_OK) {
   fprintf(stderr, "cannot connect to AVL servern");
   exit(2);
 }

The avl_connect() function establishes a connection with the AVLP service; it must be called before any other AVLP routines.

For an occupancy sensor we use a motion detector mounted on the ceiling over the passenger compartment (Figure 2). When motion is detected, the sensor closes a switch. This switch is wired to one of the inputs on the SPARK in-vehicle telematics device. The avl_rio() function returns the state of all the external digital I/O signals, including our motion detector. The bits are defined as follows:

 BIT  HEX VALUE  DESCRIPTION
  5       8      Ignition (key-on) signal
  4      10      12V INPUT2 (ALARM) signal
  5      20      12V INPUT3 (PANIC) signal
  6      40      DOOR UNLOCK OUTPUT
  7      80      ALARM OUTPUT (starter disable)

Figure 2. Ceiling-Mounted Motion Sensor

We connect the INPUT2 (ALARM) signal to the outputs of the motion detector. The following code fragment demonstrates how we read the detector status using the avlio library:

 #define MOTION_DETECTOR 0x10
 
 x = avl_rio();
 /* negative return means error */
 if (x >= 0) {
   if (x & MOTION_DETECTOR)
     /* Motion Detected */
   else
     /* Motion Not Detected */
 }

The temperature sensor is an analog sensor (Figure 3). It produces a voltage signal proportional to the temperature it detects. We connect this sensor to the analog input of the SPARK in-vehicle telematics device. This value is read using the avl_rai() function (read analog inputs). There are four different analog readings available, as follows:

 PORT   SIGNAL            VALUE
  0     External          volts * 125000
  1     Car Battery       volts * 125000
  2     Board Temp.       degrees C * 4
  3     Regulated Power   volts * 1000000

Figure 3. Temperature Sensor

Our temperature sensor is connected to the External input on port 0. The following code fragment demonstrates reading the value:

 x = avl_rai(0);
 if (x < 0) {
   fprintf(stderr, "avl_rai failedn");
 }
 else {
   Temperature = x;
   printf("Temperature: %d degrees Fn",
          Temperature/1250);
 }

The raw value is stored into the variable Temperature. The sensor supplies one volt at 100°F, and the avl_rai() function returns volts times 125,000. Therefore, the value returned by avl_rai() divided by 1,250 will be degrees Fahrenheit.

Putting It All Together

Our heatstroke warning system will be a simple closed-loop system. It will read the state of the system and take action if needed. The basic algorithm expressed in C pseudo-code is shown in Listing 1.

Listing 1. Basic Algorithm in C Pseudo-Code

The pseudo-code is a bit simplified, but the actual C implementation is not that different. We will implement the algorithm as a simple state machine. The state transition diagram is shown in Figure 4.

Figure 4. State Transition Diagram

The basic heatstroke warning program, about 150 lines of C code, is shown in Listing 2 [available at ftp://ftp.ssc.com/pub/elj/listings/issue07/5570.tgz]. The program calls the function sound_alarm() to sound the warning. The example sends a short message to an e-mail address via the wireless data link of the in-vehicle telematics unit. It also turns on the alarm output of the telematics in-vehicle device, which we have wired to a talking siren module programmed to say “Heatstroke warning. Occupants may be in danger” (Figure 5). The alarm output could be wired to various devices, such as a simple tone-generating siren, light flasher or horn.

Figure 5. Programmable Voice Siren

Let's examine the sound_alarm() code more closely. It first calls avl_pnic(), which causes the in-vehicle unit to transmit a position-encoded PANIC signal to the SPARK network service. The SPARK service can be configured to take various actions upon receiving this event. Since we're focusing on the embedded in-vehicle environment, we won't go into those details, but in fact, a real-world implementation of our heatstroke warning system could benefit from the SPARK open-architecture at the server and middleware layers. One example might be integration with an emergency call-center service (i.e., an OnStar-type service). Our sound_alarm() function next calls the avl_tmsg() function. This AVLP service sends an e-mail message over the SPARK in-vehicle wireless data connection. In our case, the message is delivered to the address specified by the ALARM_ADDR setting. We might use the e-mail address of our pager or cell phone to provide instant remote notification of the dangerous situation. The sound_alarm() routine can be modified to take whatever other actions one might desire.

When the heatstroke warning system first detects a high temperature, it goes to the stage-one state. It then waits one minute for the temperature to stabilize (to ensure it wasn't a spurious reading). If, after the one-minute stabilization period, motion was detected at any time during the period, it goes into full alarm state. It sounds the alarm for five minutes and then delays for ten minutes and returns to the stage-one condition.

If, during the stage-one countdown, the temperature falls below 90% of the danger limit, then no alarm will be triggered, and the program will resume scanning mode.

Turning the key on in any state will cancel any alarms and put the warning system into an idle state. The warning system does not operate when the vehicle is being driven, only when it is parked with the key off.

Testing Our Application

The in-vehicle platform has no hard disks or floppy disks. The filesystems are read-only. There is no keyboard, no video card and no monitor. We must rely heavily on the Ethernet LAN connection for development purposes. Fortunately, this is easy with the SPARK development system, partially due to the fact that the in-vehicle platform runs Linux and thus includes a very effective TCP/IP suite.

The SPARK kit provides an easy way to upload our programs to the in-vehicle unit using any FTP client. Listing 3 shows an example of compiling our heatstroke warning system program, heatwarn, and copying the executable to a RAM disk area on the in-vehicle platform.

Listing 3. Compiling heatwarn and Copying the Executable to a RAM Disk Area on the In-Vehicle Platform

Listing 3 assumes the IP address of the in-vehicle unit on the LAN is set to 10.0.0.10. After uploading the program, we can Telnet to the in-vehicle unit from our development host and run the program. Programs uploaded via FTP are stored in the directory /var/code. The following sequence shows running our heatwarn application:

 $ telnet 10.0.0.10
 Trying 10.0.0.10...
 Connected to 10.0.0.10
 Escape character is `^]'.
 avl login: root
 Password:
 
 # cd /var/code
 # ls
 heatwarn
 # heatwarn

We might add some diagnostic output messages for debugging and to verify the operation of our application. Obviously, we can't put our neighbor's kids in the backseat of the car on a hot day and see if they wilt. We'll need to experiment with connecting the sensors in a controlled laboratory environment to get everything working properly before we begin to wire it into the vehicle.

One advantage of testing using the RAM disk is that if our program crashes or hangs, we simply reset the in-vehicle device, and everything goes back to normal. The RAM disk gets reinitialized each time the in-vehicle device boots.

The SPARK in-vehicle platform also supports remote mounting of NFS filesystems. If the development platform is capable of acting as an NFS server and exporting a filesystem, the in-vehicle platform may run applications directly from that exported filesystem. Details can be found in the SPARK kit documentation.

Installing the Application

Once we're satisfied with the operation of the program, we need a way to load it onto the in-vehicle unit, storing to something more permanent then a RAM disk. Again, the SPARK tools include everything we need.

Let's return to the top-level Makefile that we used to create our development environment. As we previously observed, it not only builds the applications under the src directory, but it also performs steps to create a ROM disk filesystem image. Specifically, it runs a tool called genromfs to build the /usr filesystem image.

The /usr filesystem on the in-vehicle unit is available for user applications, such as our heatstroke warning system application. To install the application, first install the application executable file into /usr/bin, and then modify the /usr/etc/rc.local script to cause it to run the application.

The SPARK tools use the romusr directory as a staging area for the /usr filesystem. The contents of the romusr directory on the development host are mirrored in the ROM filesystem image created by the standard top-level Makefile. The default environment shows how to install the lcdoper sample application described elsewhere. We will replace this application with our heatwarn application. In essence, all we have to do is copy our heatwarn binary to the romusr/bin directory and modify the romusr/etc/rc.local script on the development host.

The SPARK development system supports an automated method for copying files to the romusr staging area. The top-level Makefile executes a script called usrtemplate.sh to load files into the romusr staging area. The default usrtemplate.sh script installs the lcdoper application. Our modified script installs our heatwarn application, as follows:

 #!/bin/sh
 
 # put your own binaries here...
 cp src/bin/heatwarn     romusr/bin

Likewise, the default romusr/etc/rc.local script runs the lcdoper application. Our modified version starts our heatwarn application:

 #
 # /usr/etc/rc.local - script executed by /etc/rc
 #
 
 # start the Heatstroke Warning System
 sleep 5
 /usr/bin/heatwarn > /dev/ttyS0 < /dev/ttyS0
 2>/var/heatwarn.err &
 
 # must exit with zero to keep init happy
 exit 0

Once we have the romusr directory ready on the development host, we need a way to build the ROM filesystem image and load it to the Flash memory of the in-vehicle unit. The top-level Makefile builds the ROM filesystem image:

 $ make
 make -C src
 make[1]: Entering directory `/data/kit/heatwarn/src'
 for i in heatwarn ; do make -C $i; done
 make[2]: Entering directory
          `/data/kit/heatwarn/src/heatwarn'
 make[2]: `heatwarn' is up to date.
 make[2]: Leaving directory
          `/data/kit/heatwarn/src/heatwarn'
 cp `find -name *.coff | sed -e s/.coff//` bin
 make[1]: Leaving directory `/data/kit/heatwarn/src'
 sh -f usrtemplate.sh
 genromfs -v -V "USR ROM Disk" -f romusr.img
 -d romusr 2> romusr.map
 $

The romusr.img file is the ROM filesystem image of the in-vehicle platform's /usr filesystem. We can use FTP on the development host to initialize and load the designated Flash memory area on the in-vehicle unit, as shown in Listing 4.

Listing 4. Using FTP on the Development Host to Initialize and Load the Designated Flash Memory Area on the In-Vehicle Unit

Note that issuing the special FTP command quote burn is what causes the Flash to be overwritten with the romusr.img image. It also causes an automatic reboot; no more FTP commands can be issued in the FTP session after the quote burn command.

If everything worked properly, our in-vehicle telematics device is now a heatstroke warning system, in addition to its built-in tracking, monitoring and security features.

The entire Heatstroke Warning System Project, with source code, Makefiles and configuration files can be downloaded from www.research.earthlink.net/avl/heatwarn.tar.gz.

Conclusion

Hopefully this article has shown how easy it is to develop your own automotive telematics applications using the EarthLink SPARK Linux development platform. We should point out, however, that we have skimmed over some of the details. Those details can be found in the SPARK developer kit documentation.

We also must stress that the system proposed here is for research purposes only. It has never been proven in real-world conditions and should not be assumed to be effective. It also should go without saying that it is never safe to leave a child alone in a vehicle, even for a few minutes.

Consumers will soon expect connectivity and services in their car to be on par with their mobile and desktop experiences. Consumers will demand choice in their in-car services just as they do in all other aspects of their lives. Closed platforms limit consumer options. Open systems and independent software developers will be central to successful telematics services of the future. The EarthLink SPARK developer kit gives developers a window to that future.

---

About the author: David Beckemeyer ([email protected]) is Distinguished Research Engineer at EarthLink, Inc. He lives in the San Francisco Bay Area and has been an open-source contributor for more than 15 years. His web site is www.bdt.com/david.

---

Copyright © 2001 Specialized Systems Consultants, Inc. All rights reserved. Embedded Linux Journal Online is a cooperative project of Embedded Linux Journal and LinuxDevices.com.

 
This article was originally published on LinuxDevices.com and has been donated to the open source community by QuinStreet Inc. Please visit LinuxToday.com for up-to-date news and articles about Linux and open source.