Spectra Aerospace & Defense is a trusted and growing platform of C5ISR companies – CALCULEX, Galleon Embedded Computing, and ArgonFDS - bringing over a half-century of rugged, mission-ready, battle-tested experience to bear in aerospace and defense applications. From high-speed data acquisition, data recording and secure, high-density storage, to computing and rugged, clear display of mission data, Spectra delivers the products and subsystems needed for the most demanding military air, land, and sea platforms. With our comprehensive portfolio of rugged products, systems, and solutions, the Spectra family of companies’ customized end-to-end solutions for the C5ISR market help military end-users achieve mission success. Simply put, Spectra's rugged solutions Capture, Process, and Display your mission-critical data in the harshest environmental conditions. In the air, at sea, on land, and in space; We simplify integration.

CAPTURE

Data Acquisition

Sensor Recording

PROCESS

Mission Computing

Encrypted Storage

NAS & File Serving

Processing & Routing

DISPLAY

Displays

Peripherals

Tablets

Workstations

Introduction

This document discusses various application uses for the family of Galleon XSR and G1 products. Applications for the XSR and G1 can be categorized into one of three areas: Capture, Processing, and Storage. Three simple concrete examples or each of these respective areas include Ethernet Recording and Packet Capture (Capture), Mission Computing (Process) and Network File Server (Store).

Other applications can span more than one of these three areas. Regardless of the application, the Galleon XSR and G1 provide a flexible approach to solving a multitude of problems for deployed platforms.

1. FAQ

As an introduction to the topic of what type of Galleon product is best suited to a given application, it is best to dive right into the most common questions Galleon receives by customers trying to decide what product to choose. This paper will then explore these questions in more detail in subsequent sections.

I don’t know what type of system I need: Recorder or NAS. What’s the difference?

 

In the simplest terms, a recorder ingests and stores a specific type of data. For example, a recorder can be used to capture all UDP datagrams containing video data. Or it can be used to test out a new radar design that outputs data in the serial FPDP (sFPDP) format. Or it can be used to capture all ethernet traffic on a network for post-mission analysis using a Packet Capture (PCAP) recording application (similar to Wireshark). A recorder can also be a combination of the different recording capabilities mentioned.

A NAS on the other hand is intended to be used as general-purpose storage. A NAS can be thought of as a repository for any type of data or files, much like a local hard drive on a computer, but accessible over a network.

The recorder performs its own file management. It takes care of creating and managing files from within a dedicated recording application. A NAS places that onus on the device accessing the NAS. The device accessing the NAS must perform the file management itself by creating, reading, writing and deleting files. The recorder can also be configured to be completely self-contained and begin recording on bootup without any outside management.

Due to the recorder being optimized for a specific application, it generally can record at a higher datarate than storing data to a NAS over a file share. A NAS is more flexible, however.

Can I use the same box as both a Recorder and a NAS?

 

Absolutely! It is common to record the data using one of the several recorder applications mentioned above and then make the recorded data available to other computers on a network through NAS file sharing. One caveat with this approach: maximum bandwidths for each ethernet interface must be considered when they are simultaneously being used for recording and file sharing. Multiple ethernet interfaces are available and can be used independently. For example, one ethernet interface could be used for recording while another is used for file sharing.

What’s the difference between a NAS and a File Server?

 

From a practical standpoint, there is very little difference. They both are used to serve files to another computer. A file server may have additional functionality such as also being designated a “boot server”. A Boot Server, with additional services running, can be used to remotely boot another computer by providing an IP address, Operating System, and Application Load to the remote computer as it powers up.

 

What’s the difference between a Server and a General-Purpose Computer?

 

A Server, as its name implies is used in a support capacity to other computers on a network: serving files, applications or operating systems. A general-purpose computer tends to execute applications locally. Depending on the type of applications it runs, it may have very different computing needs from a Server.

 

What processor should I choose? Should I choose a faster processor or more cores?

 

It depends upon the application. Some possible uses are shown below with Galleon’s current processor offerings. Read further for additional details.

Figure 1, Processor Options.

 

2. Flexible Architecture

 

The Galleon XSR and smaller G1 provide flexible architectures for enabling a variety of military use applications. More than just simply recorders, the XSR and G1 can be used to capture many different types of I/O, process large amounts of data, serve files to operators or other computers and store data for archival and retrieval. Exactly how much I/O, processing and storage is needed depends on the application, of course.

For example, there may be little need for extensive data storage in a mission computer. A signal processing application on the other hand may require significantly more storage and compute capability than a standard Ethernet recorder might. Other non-processing intensive applications may be able to function with a very low-power processor. Whatever the case, there are many selectable hardware and software features available as options on the XSR and G1 that can be customized based on the application.

 

Figure 2, Application Examples with the XSR and G1.

Some of the more common XSR and G1 application uses include:

  • Flight-test data logging
  • Network file sharing (Linux and Windows)
  • Boot server
  • Mission Planning and Map Server
  • Ethernet Packet Capture (PCAP)
  • Video processing, recording and playback
  • Radar/Sonar processing, recording and playback
  • ISR (SIGINT/COMINT) processing, recording and playback
  • Encryption / decryption
  • Virtualization

Central to the design of the XSR and G1 is the ability to pick and choose a configuration based on the following six major system components:

  • Processor
  • Operating System
  • Memory Capacity
  • I/O Capabilities
  • Encryption
  • Removable Storage Capacity

I/O and storage needs are the primary differentiators between applications. Due to their modular designs, the XSR and G1 can be configured to match the appropriate I/O and storage to the application.

I/O is primarily accomplished though selection of the appropriate high-speed XMC expansion devices (XSR) with slower speed or auxiliary I/O available through internal mini-PCIe expansion slots (XSR & G1). Both the XSR and G1 provide Gigabit and 10GbE network connectivity natively.

The XSR and G1 have a wide range of SSD storage types and capacities. Systems can be built without any local storage (e.g. PXE network boot) or built for signal processing systems that require very large amounts of removable storage (10’s of Terabytes). In-line FIPS 140-2 encryption is also on option. This scalable and flexible approach to data storage allows the XSR and G1 to be configured for short or long duration missions for any embedded military application.

Figure 3, Multi-Use Architecture.

 

3. Applications

Processing Applications

 

There are many different types of processing applications. Two of the most common uses for the XSR and G1 are Mission Computing and Video Processing. These “processing applications” have very different hardware and software needs, however. Those differences are explained below.

 

Mission Computing

Mission Computing does not typically involve the use of large amounts of data storage as is usually required for video processors. Depending on where they are installed, mission computers generally have more size, weight and power (SWaP) constraints than a video processor might. They may also have more platform-specific requirements such as communication with MIL-STD-1553 devices, ARINC-429 avionics buses, CAN bus devices, additional discrete and serial devices, control panels / displays and other Human-Machine Interfaces (HMI). In this capacity, the Galleon XSR may be configured without a removable data cartridge, saving on complexity, weight and power. Mission computers may require high-performance graphics display requirements but they have very different compute requirements than video processors.

Figure 4, XSR Mission Computer with reduced or no data storage.

Mission computers typically service many disparate slow-rate I/O signals. These do not require high clock rate processors but can benefit from reduced complexity by processing the signals independently of each other in separate threads. In this case, more cores and more threads running at a slower clock rate is better suited for this application.

Video Processing

 

In contrast to the varied need of a mission processor, video processing applications usually input a finite number of the same type of video sources (1 to 4 HD-SDI cameras, for example).

In addition, due to the vast amount of data that can be generated by a high-speed front-end video stream, many pre-processing, filtering and compression techniques are often performed in order to make the data more presentable to operators and easier to archive to storage. Of course, processing of any type of video, imagery or signal data comes at a cost in terms of additional compute power required. Higher clock rate processors are chosen for the video processor version of the XSR.

This type of processing requires very high clock rate main processors to manage the large amounts of data. Compression can benefit from a faster single-threaded processor as some compression algorithms are not well suited to a multi-core / multi-threaded approach. However, other image processing algorithms benefit greatly from using GPGPU offload engine capability where the data can be processed in a parallel fashion in dedicated multicore graphics processors.

Relative to some of the more powerful Intel Xeon processors, the low-power Intel C2758 processor in the G1 is still quite capable for the right application. However, the G1 doesn’t have a GPU and is limited in its ability to receive video signals (other than by ethernet). For this reason, it is generally not suitable for video processing compute-intensive applications.

Figure 5, Video Processor

 

Data Recording

 

Example applications of the Galleon XSR and G1 used as a data recorder include Flight Test Data Logging, Ethernet Packet Capture (PCAP) recording, Gigabit / 10 Gigabit TCP and UDP recording, sFPDP recording and Video recording. Other applications are possible by incorporating different I/O modules for specific I/O types.

In the default configuration, the Galleon XSR has five native Gigabit Ethernet ports. These ports can be dedicated for PCAP Ethernet recording, TCP recording, UDP recording or any other type of Ethernet recording. This represents the most basic and common recorder configuration of the XSR. It does not require special purpose I/O hardware.

Galleon provides the recording software for PCAP, TCP and UDP recording. These are complete turn-key applications that allow the customer to begin recording on day one with little to no software integration.

Figure 6, UDP Recorder Application.

In another capacity, the XSR can be configured as a Serial FPDP recorder. Serial FPDP is typically seen in Radar and other signal processing applications.

The XSR Serial FPDP recorder can connect to up to four Serial FPDP channels operating at link speeds of 2.125, 2.5, 3.125, 4.25, 5, 6.25, 8.5, 10, and 10.3125 Gbps. The link speed is individually controlled by SW for each link. The recorder receives Serial FPDP frames with data payload on one or more of the links.

Similar to the UDP recorder, the sFPDP recorder comes with its own turn-key application for controlling recorder operation. The Serial FPDP Record Manager (SFRM) application controls the recording either from a command line or through and an SDK/API incorporated into the user’s application. The figure below shows an overview of this application, and how it relates to the operating system and hardware.

Figure 7, Serial FPDP Record Manager Application.

The SFRM can be configured to start automatically when the recorder boots. Once the SFRM is started, a remote application can use the Serial FPDP Record Manager API to control the SFRM through a TCP connection. This API lets the remote application:

  • Add a Serial FPDP channel to the recorder
  • Remove a Serial FPDP channel from the recorder
  • Start recording from all Serial FPDP channels
  • Stop recording on all Serial FPDP channels
  • Get status information for an active recording session

CP50 Control Panel (option)

In most cases, the recorder is installed into a system which has an existing computer system. In such cases, the control API mentioned above is used for that computer system to control the recorder. The Galleon API can be run on Linux or Windows computers.

Alternatively, if it is desired to control a recorder separately, or if there is no other computer system available, then the CP50 may be used. This is a control panel with a simple display and user interface. The CP50 is configured to match the configuration of the XSR that it is controlling (number of data and video inputs, etc).

Figure 8, CP50 Control Panel

The CP50 is NVIS compatible, and DZUS mounted, and the only electrical connection required is to the XSR (including power).

 

Networked Attached Storage (NAS) / Network File Server

Having fast SSD storage and multiple network interfaces, the XSR and G1 is very well suited for use as a file server. To facilitate this application, Galleon offers XSRs and G1s preinstalled with Linux, Windows Storage Server, or FreeNAS as the operating system.

Figure 9, Network Boot and File Server. 

The default configuration of the Galleon XSR has five native Gigabit Ethernet ports. Two of the five ports are capable of 10GBASE-T by adding two MIL-DTL-38999 Twinax TV μCom connectors to the XSR. Four additional Ethernet ports (Gigabit or 10 Gigabit) may be added through the addition of an XMC card for a total of nine ethernet ports. All of the Ethernet ports can be user configurable, dedicated for recording or used to facilitate file serving over a Network Attached Storage (NAS) or Storage Area Network (SAN).

One of several applications may be used as file servers in a NAS environment: FreeNAS, NFS, SMB/CIFS and FTP.

SMB/CIFS protocol is commonly used as the network share protocol for the Microsoft Windows operating system. NFS and FTP are commonly used for Linux network sharing. FreeNAS is perhaps the best of both worlds incorporating both Linux and Windows sharing by using its own slimmed down O/S dedicated for file sharing.

For applications where the very highest performance and largest storage capacities are not necessary, Galleon offers a smaller, reduced power architecture in the G1 microserver. The same discussion regarding NAS applications applies to the G1 but with reduced SWaP and at a lower cost. The G1 may also be used for reduced SWaP Ethernet PCAP, TCP or UDP recording.

Multi-Use

An application may not be limited to just storage, processing or capture, but in fact, may use all of the above. In the example shown in Figure 10, the following are performed concurrently in a single XSR:

  • I/O Interface with FPGA processing
  • Recording of raw and compressed imagery
  • Image Processing (Stabilization, Orthorectification, Mosaicing, etc)
  • Encryption
  • NAS File Server (NFS, SMB/CIFS, FTP, etc)
  • Physical offload of data storage
  • Flight mission planning

Figure 10, Multi-Use Example 

DOWNLOAD PDF