RSTA-MEP and the Linux Crewstation

Automatically detect the enemy in the dark and notify friendly units where he is.

We recently completed a prototype Linux crewstation for the
Reconnaissance, Surveillance and Target Acquisition Mission
Equipment Package (RSTA-MEP). This article briefly describes
the whole system, then focuses on the crewstation portion.
The Raytheon RSTA-MEP program provides the capability to
assess the battlefield quickly through real-time information from the fusion
of onboard and offboard sensors. Advances in sensors and software
provides for wide-area-search (WAS) imaging, automatic target
detection (ATD) and aided target recognition (AiTR)
capabilities. These capabilities provide the crew with real-time data,
including target position, classification and priority. Combining
this with the US Army's Tactical Internet allows the crew to
formulate and contribute to a common operating picture of friendly
and enemy forces. This vehicle is a technology demonstrator to show
what emerging capabilities can be added into existing and future
reconnaissance vehicles.

In its current incarnation, the vehicle has thermal sights to allow the user
to see in the daytime or at night. The primary sensors on the mast are
a long-range Forward Looking Infrared (FLIR) sensor, an Inertial
Navigation System (INS) and a Global Positioning System (GPS) receiver.
In addition to what's on the mast, there are several Raytheon
NightSight infrared sensors attached to the vehicle so that
the rest of the crew can look at the immediate area around the
vehicle.

The mast is four meters high, and
including the height of the vehicle,
the sight is over five meters high. The vehicle
has a three-member crew: driver, commander and
scout/operator. The driver can also use the NightSight
sensors to drive in the dark and look around
for security purposes. The commander also has
controls for the NightSight sensors, operates the
connection to the Tactical Internet and directs
the other two. The scout/operator uses the Linux
crewstation to operate the mast-mounted sensors
and their associated embedded systems.

The RSTA-MEP system is mounted onto an H1 Hummer and consists of a
mast-mounted sight, embedded computers and a crewstation PC running
Linux (Figure 1).
These parts connect together as shown in
Figure 2.

Figure 1. RSTA-MEP system mounted on a Hummer with mast extended. The
sensors are at the top of the mast; the embedded systems are in white
boxes on the back. The crewstation computer is inside the vehicle.

Figure 2. Crewstation Computer Connections and Modules

The Embedded Side

The embedded computers are digital signal
processors that control the mechanics and
electronics of the sensor (for example, pointing the
sensor or cooling its detector) and some of the
image processing. PowerPC boards
running VxWorks and single-board computers running
Microsoft Windows NT and Sun Solaris also are used. The applications
running on these computers include the Force
XXI Battle Command Brigade and Below (FBCB2, a
US military digital command and control system),
target detection and recognition, real-time image
processing and communications. The package also
includes a GPS receiver, inertial navigation
system and digital map functionality. The
embedded systems communicate with each other
using Ethernet and Virtual Interface protocol (VI)
on Fibre Channel.

Connecting to the Crewstation

The prototype Linux crewstation is the successor to an earlier system.
The ideal case would have been for our new crewstation to fit in
exactly the way the predecessor crewstation had.
Our initial attempts to use VI on Fibre Channel failed. Our embedded
systems group had considerable experience with vendor compatibility
issues, so in selecting Fibre Channel hardware we were limited to
vendors who supplied cards and drivers for both VxWorks and Linux. We
couldn't find any of those who supported VI protocol. Our second
attempt was to try to use disk emulation and imitate a hard drive
connected to Fibre Channel, so we could at least stay on the same media.

The results there also were unsatisfactory, so we went to
gigabit Ethernet. Ethernet would carry both the video from the sensor and
the command and status data between the crewstation and the embedded
systems.
When looking at gigabit Ethernet, the home audience must consider
four things: packet size, media, interconnecting and network interface card.
Regular Ethernet has a maximum packet size of 1,500 bytes. An
emerging standard for gigabit Ethernet is to allow a 9,000 byte
maximum, called jumbo packets. For this project, our concerns about
vendor compatibility between the embedded side and the Linux side
pushed us to regular packet size.

The second consideration is media. Gigabit Ethernet cards come in
two varieties, copper and optical fiber. Although copper is susceptible
to electromagnetic interference (EMI), fiber is mechanically delicate.
We chose
copper because it's cheaper. If EMI became a problem, we always
could get an optical card later without changing software. The choice
of copper also meant we were compatible with our lab's
infrastructure, courtesy of autonegotiation. Our existing network was
10/100 copper.

The third consideration is interconnect. The situation doesn't
change too much from 10/100 Ethernet; you have switches, hubs and
crossover cables.
Switches route traffic so it's seen only by the
intended recipient. They handle connections with differing speeds and
duplexes, and they have the all-important blinky lights (the status
lights on the switch that blink to show activity) to help with
debugging. The disadvantages of switches are the cost and that you
need a managed switch if you want to use a packet sniffer.

Hubs are the second choice. On the plus side, they are cheaper than
switches and have the status lights. On the minus side, we know of no hubs
for gigabit Ethernet (only switches), so if you
use a 10/100 hub, you sacrifice speed. Hubs also send all packets
everywhere, which is good if you're trying to sniff packets but bad
if you're trying to limit the amount of traffic on an interface.

Crossover cables are the simplest option. They're the cheapest
choice; they require no additional equipment, and you can be sure that
no packets are coming from an outside source. On the other hand, there
are no blinky lights, no way to connect an outside packet sniffer, and
if one interface goes down (common for restarting embedded hardware),
so does the other.

We chose switches, although the choice between switches and
crossover cables is still a subject of religious debate.
We also can pass on a caution about gigabit cabling. Professionally
made category 5e or 6 cables are preferable to home-brew cables.

The fourth consideration is your network interface card; they
generally come in 32- and 64-bit flavors. The 64-bit cards typically
perform better with less draw on your PCI bus' resources. Although we
didn't perform a trade study on available products, we chose the
Intel Pro/1000 Server Adapter.

We chose to use TCP/IP on Ethernet. Although TCP is slower than UDP,
it is a reliable protocol that compensates for any dropped, duplicated
or reordered packets. We wanted to get the best-quality video
in the face of possible EMI on the vehicle, so we deemed that built-in error
correction was essential. Also, because no information is lost, duplicated
or delivered out of order, command and status information would be
reliable. When coding the socket layer for this, we had to tune the
sizes of the socket send and receive buffers (using setsockopt with the
SOL_SOCKET SO_RCVBUF and SO_SNDBUF options) to get enough throughput for
the video. We also turned off Nagle's algorithm (setsockopt with IPPROTO_TCP
and TCP_NODELAY) to reduce the latency between the crewstation and the
embedded system, making it more responsive to sensor-pointing commands
from the grips attached to the crewstation.