Time-stamp: <Tue 09-Dec-2003 11:35:29 am>



                                  H I A P E R

                 Aircraft Data Acquisition System Requirements

                                by John Wasinger


1.  Introduction

   The HIAPER aircraft data system (ADS-III) consists of hardware and software
   to provide a flexible, expandable, and technically advanced means of
   acquiring data from a wide variety of instruments on-board a GulfStream G-V
   aircraft.  This ADS shall accommodate the recording of user supplied
   instrumentation data streams via industry standard interfaces.  There will
   only be limited support for custom interfaces and users will be strongly
   encouraged to use industry standard instrument interfaces.

   Currently the C-130's ADS-II hardware design contained several Distributed
   Sampling Modules (DSMs) that collected the instrument data via a/d
   converters, custom digital interface cards, and serial ports.  These DSMs
   then transmitted the collected data once a second to an on-board central
   server computer (a.k.a. Hercules).  Hercules stored the the data on a
   removable disk as well as provided a real-time Window Display System (WINDS)
   access to the data.

   This Document augments the HIAPER Aircraft Data Acquisition System
   Requirements document which describes the functional requirements, instrument
   interfaces, and development plan of the new ADS-III.  This document was
   prepared for the Critical Design Review presented on November 20th 2003.  It
   describes the procedures software development, maintenance, and performance
   testing.


2.  Development Process

   The following guidelines shall be taken to ensure that an accountable
   Aircraft Data System is developed.  The goal of these guidelines is to
   establish traceability of changes throughout the history of the new systems
   development.


2.1.  Software Revision Control

   To develop an accountability of changes to the files the following practices
   shall be followed:

   - Ensure that developers are able to fully build the system from only files
     checked out from the CVS repository to their user account folder.    Users
     should keep their development files in their user accounts to avoid
     confusion with other developers.

   - Reserve the use of the ads account for debugging in the lab and for the
     aircraft only.

   - Erase the code from the public /jnet/shared/ads-iii/[..] and
     /jnet/shared/include/[..] folders after use.  These directories shall act
     as a loading point when debugging from the lab, and loading onto the
     aircraft.

   - Always check in changes with a brief note describing the change.

   - Before developing on-board the aircraft, copy the last version of code to a
     folder named after the last project flown.  Note that this is not a means
     of revision control.  It is simply an act to save files that may have not
     been checked in and labeled yet.  These older versions shall be deleted
     after the changes are checked back in.

   - Always generate build labels that 'tag' the file versions used for each
     project release before and after the project was successfully flown.  These
     tag labels shall be published in a change log.  These tags will give the
     developers the ability to re-create older projects when needed.

   - Prior to the first flight of a project the DataServer's system disk shall
     be archived to a removable data storage hard disk.  This done to avoid any
     catastrophes where the system disk crashes in the field.


2.2.  File Dependencies

   To reduce the amount of maintenance to the various makefiles when adding or
   removing new files; the makefiles will be programmed to scan all of the
   directories to determine what to build.  All files in the /class/ folder will
   be compiled into an appropriate library (i.e. libdsm.a or libdisc.a).  All
   files in the /src/ folder will be built as executable programs that are
   either loaded on the DSM or run directly on the server computer.


2.3.  Build Features

   The following steps shall be made to build the system from the user's
   /ads-iii/ folder:

   - make clean     <- optional, removes all previously compiled binaries

   - make depend    <- optional, use if any '#include ...' changes were made

   - make           <- required, use for either a full or partial build

   - make debug     <- optional, generates debug information in code for GDB.

   - make install   <- required, copies executable binaries to
                                 $RAF/ads-iii/dsm/bin/ and
                                 $RAF/ads-iii/disc/bin/ directories

   Note that the 'make depend' modifies the makefile by appending the list of
   file dependencies to the end of that makefile.


2.4.  Debugging

   To trace the program flow, the GNU Debugger (GDB) will be used for both the
   VxWorks operating system (DSM) and the Linux operating system (DataServer).
   It provides the ability to step through code and examine variables.

   In order to debug a selection files only (without de-optimizing other files)
   the code must build in the following fashion:

   - make clean; make

   - rm ../bin/<file(s)-to-debug>.o

   - make debug; make install

   Note that it is possible to debug optimized code...

   "Unlike most other C compilers, GCC allows you to use -g with -O.  The
   shortcuts taken by optimized code may occasionally produce surprising
   results: some variables you declared may not exist at all; flow of control
   may briefly move where you did not expect it; some statements may not be
   executed because they compute constant results or their values were already
   at hand; some statements may execute in different places because they were
   moved out of loops." - gcc manual


3.  DataServer

   The DataServer computer is an Intel based rack mounted server running Linux.

   This computer shall control all of the DSMs and provide both on board and
   ground based scientists access to the collected data during the flight.


3.1.  DataServer Processes

   The DataServer shall consist of three tasks for controlling and recording the
   DSMs and Instruments:  discWin, discComm, and discRecord.


3.1.1.  discWin

   The discWin task shall provide the operator on the aircraft the ability to
   control the instruments through a Graphical User Interface (GUI).  This
   process will send and receive internal messages with the discComm task to
   convey the instrument control.

   An additional Java applet acting as a discWin interface can be run from the
   ground (discWinRemote).  This ground based system shall contain a subset of
   control interfaces for the investigators instrument only.


3.1.2.  discComm

   The central task that spawns the operator's discWin and the discRecord tasks
   is discComm.  Its primary purpose is culminate all of the periodic
   (synchronous) data prior to instructing discRecord to record the block of
   data.  In the event of receiving non-periodic (asynchronous) data, the
   discComm task will instruct the discRecord task to store it immediately.

   This task shall also act as a router to relay control from the ground or
   operator to the instrument.  The control command shall be echoed to either
   the on-board or on-ground operators no matter where the request originates.


3.1.3.  discRecord

   This tasks primary purpose is to provide access to the file system to create
   the '.ads' data file.


3.2.  Header Build

   The current hdrbld application generates a binary file that is used by both
   the DSMs and the post processor to define the structure of the recorded data.

   To provide more ability to the developer this file shall be stored as a
   meta-data based (text) file such that the variables and their types are
   spelled out.  This will require a change to an API that is used by the DSMs,
   post processor, and hdrbld.  This API parses the meta-data based data
   structure file.


3.3.  header.h

   The required data structures for all instruments are defined in header.h.
   This file is needed by hdrbld, the dsmSync processes, and the post processor.
   When hdrbld is executed the configuration for the given flight is defined.

   Currently the header.h file that defines the recorded data structure for
   every device has become too large.  Additionally its inclusion in multiple
   source files causes minor changes to code to cause excessive amounts of code
   to be re-compiled.  This file will be broken up into three files:

   - constants.h   <- #define and constants definitions

   - HdrBlk.h      <- a common structure section that defines device locations
                      (i.e. Fl, Sh, Blk, etc...)

   - DataBlk.h     <- all the data structures that define the types of data
                      measured from each device


3.4.  Hard Drives

   The DataServer will have a two redundant removable hard drives for storing
   the flight data.  It will also have a fixed hard drive for storing its
   operating system, system software, and DSM software.


3.5.  Raw '.ads' File

   The DataServer shall store the raw binary '.ads' file to the redundant hard
   disks to be made available to display system.  The format of this file shall
   remain the same for back-wards compatibility to present ADS-II.


4.  Distributed Sampling Module (DSM)

   The DSMs are Arcom VIPER single board computers running VxWorks.  The VIPER
   is a PC-104 conforming board with an xScale processor.  This board features 5
   serial ports, 2 USB 1.1 host capable OpenHCI ports, 8 digital input, 8
   digital output, and a 32-bit ISA bus.

   DSM's can vary from one another based upon their hardware configuration.

   At boot up the DSMs shall load their executable tasks from the DataServer
   across the data-network.  The header that defines the structure of the data
   shall then be loaded from the DataServer by the dsmAsync process (described
   below).


4.1.  DSM Processes

   The DSM's real-time operating system shall consist of three tasks:  dsmAsync,
   dsmSync, and dsmComm.


4.1.1.  dsmSync

   This task shall poll the scientific instruments at various rates for data.
   For instance the ARINC buffer will be polled every 10 msec, digital pressure
   every 200 msec, etc...  The analog data will be collected from their buffers
   at 10, 100, 1000, and 10000 Hz sampling rates.  Serial based instruments will
   either be periodically prompted to generate data, or they will generate the
   data autonomously.  In either case the interrupt service routine allocated to
   the instrument's serial port will receive the data.


4.1.2.  dsmAsync

   This task shall process data received from instruments that do not operate on
   a periodic basis.  For instance the PMS 2D probes will interrupt the DSM when
   they have received a block of asynchronous data for recording.  The dsmAsync
   will idle until it is instructed to gather this data for recording by the
   interrupt routine.


4.1.3.  dsmComm

   This task shall act as a message router between dsmAsync, dsmSync, and
   discComm.  Its primary purpose is to send instrument data received from
   dsmSync or dsmAsync back to discComm for recording.  This task will also
   deliver instrument control messages from the DataServer.


4.2.  Cross Compilation

   In order to generate code for the VIPER platform a cross compiler tool chain
   is needed.  These tools will be located in the following folders:

     $RAF/VxWorks/gnutools/arm-elf/bin       <cross compilers and linkers>*
     $RAF/VxWorks/viper/install/lib          <VxWorks real time libraries>.a
     $RAF/VxWorks/viper/install/include/...  <VxWorks real time libraries>.h

   This is an abbreviated version of the actual tool set provided by VxWorks.
   The actual full tree will contain tools for configuring VxWorks to the
   hardware.  A corresponding makefile will be created to use these.


4.3.  Flash Memory

   There is 16Mb of non-removable flash disk space available to store programs
   on the VIPER Single Board Computer.  The current MVE162 system has up to 1Mb.

   The VxWorks system provides a file system that accesses this non-volatile
   memory.


4.4.  CompactFlash card

   The VIPER board also supports an additional removable Type II CompactFlash
   card.  These cards can store up to 2.0 GB of scientific data.

   This card shall be used in situations where a DataServer is not available to
   store the recorded data.


4.5.  Anything I/O board

   The Anything I/O is a PC-104 board with a Complex Programmable Logic Device
   (CPLD).  The CPLD's program file shall be uploaded to the DSM and stored on
   the flash memory for re-use in the event of a mid-air reboot situation.


4.6.  Jxi2 IRIG-B time/frequency processor card

   The Jxi2 is a PC-104 board that provides interrupts to the DSM system every
   100 Hz.  Every DSM shall be outfitted with their own Jxi2 timer card. The
   Jxi2 card will also provide a reference frequency derived from its
   disciplined oscillator for use on the A/D card to synchronize A/D conversions.

   The DSM shall time sync with the IRIG-B by decoding its digitally encoded
   time prior to take off.  While in flight the DSM will receive one pulse per
   second (1 PPS).  To ensure that pulses are not missed the DSM will decode the
   binary time every 10 minutes.  Several decoded time samples will be taken at
   that point (and prior to take off) to ensure a correct reading.


4.7.  VIPER serial ports

   The original VME based system used a smart multi-port serial card.  This card
   had the capability to buffer the messages and then interrupt the system based
   on a specified string length or terminating string.  This behavior will be
   emulated by creating multiple interrupt routines for each of the four
   embedded serial UART ports.

   These UARTs shall generate interrupts when their FIFO buffer is half full or
   when a time delay is detected in the character flow.


4.8.  Eight port serial card

   An additional eight port UART serial card will be provided.  These UARTs
   shall also generate interrupts when their FIFO buffer is half full or when a
   time delay is detected in the character flow.

   These ports have an additional feature where they can generate interrupts
   based upon a single character detection.  These ports shall be used in the
   event where a time delay is not detectable by the card but a termination
   character is used.


4.9.  ARINC 429 board

   A PC-104 based ARINC board will be placed in the forward DSM.  This board
   will sample avionics data from the aircraft's Air Data Computer (ADC),
   Inertial reference System (IRS), and Global Positioning System (GPS).

   This card shall gather the collected ARINC labels into a buffer that is
   polled by the dsmSync task.


4.10.  Universal Serial Bus (USB)

   The USB version 1.1 is capable of transmitting serial data up to 12 Mbps in
   half duplex mode.  The VIPER board provides this bus as a host.  Scientific
   devices which need to utilize this high rate of data capturing can be fitted
   with a USB client interface.  Guidelines for the software development of the
   USB data protocol, and hardware installation shall be provided by the RAF.

   The use of the VIPER's USB ports will replace the original specification for
   the implementation for the HDLC.


4.11.  Analog to Digital converter card

   An in-house designed A/D converter card will be available for the DSM's.
   This card will offer six (or more, depending on layout constraints)
   independent 16-bit A/D converter channels which will each provide data rates
   of up to 10 KHz.  Conversion timing will be slaved to a clock output from the
   Jxi2 card in the DSM.  A/D cards may be added to the DSM as needed to expand
   the number of analog input channels.  Signal offset and internal calibration
   capability will be included.  The programmable gains (x 1, 2, 4, 20) shall be
   defined in header build.


5.  TimeServer

   The TimeServer is a device that is connects to the GPS antenna.  This device
   provides an IRIG-B pulse as well as a Network Time Protocol (NTP) service.
   This device shall periodically transmit the UTC (day hour:min:sec) throughout
   the flight.

   All systems shall use this device to synchronize their operations.


6.  Data Network

   The TCP/UDP/IP based data network connects all of the DSMs to the DataServer.


6.1.  Terminal Access

   Each DSM will be accessible via a serial link to its terminal.  Terminal
   access is needed for debugging the DSM during startup.  Since there will not
   be any serial cables routed to the DSMs a DigiOne device will be used to
   provide serial access via the Data Network.  Since terminal access is only
   needed during debug, startup, and restarting the added traffic to the data
   network will not occur during the peak time when the DSMs are running and
   sending data.

   The DataServer shall run a daemon that simulates basic serial terminal access
   to each of the DSMs by transmitting the serial data to the Ethernet
   controlled DigiOne device.


7.  Display Network

   The TCP/UDP/IP based display network connects all of the scientists to the
   DataServer.  It provides them with the following services:


7.1.  Image Capturing

   Several cameras will take digital images once a second and store them on the
   DataServer as separate files.  These cameras will time stamp their JPEG
   images and transmit them to the DataServer via the display-net.  These
   cameras will have their clocks synchronized via the Network Time Protocol.


8.  Scientific Instruments

   All of the instrument control from either the on-board or on-ground
   scientists shall be sent to the DataServer's discWin application.  This
   application will update its control display and relay the control to the
   instrument on the data network or display network.  Note that discWin will
   only display the current control status of instruments that are controlled by
   a DSM.


8.1.  Operator's Instrument Control

   The operator at the DataServer has the ability to activate and adjust
   individual scientific instruments that are connected to the DSMs.  The DSM's
   digital inputs and outputs shall be used for this control.


8.2.  Automatic Instrument Control

   Some scientific instruments need to know data values such as true air speed
   or altitude in order to perform their embedded calculations.  These data
   values shall be periodically broadcast across both the data and display
   networks from the DataServer.


8.3.  Recorded Instruments

   Instruments that are provided by scientific investigators will connect
   directly with the data network.  In order to record their data at a 5-10
   microsecond time precision they must be outfitted with their own Jxi2 timer
   card or they can use the Network Time Protocol (NTP) and synchronize their
   time within 5-10 milliseconds.


8.4.  Non-Recorded Instruments

   The aircraft (on occasion) will carry scientific instruments that provide
   their own recording capabilities.  The DataServer shall provide access to
   control these devices to the ground based scientists by routing the requests
   to their instruments.  The current control state of these instruments will
   not be stored or displayed by the DataServer.


9.  SATCOM Connection

   The satellite communications modem will provide access between the DataServer
   and any ground based system.  The SATCOM modem will provide a Point-to-Point
   Protocol (PPP) connection to the DataServer.

   The DataServer shall act as a gateway server and provide access to both the
   data- and display- networks.


10.  Network Architecture

                         data-net         display-net
                            |                  |
                            |                  |
     <instrument>---<DSM>---|                  |---<laptop>
                      :     |                  |       :
                      :     |                  |       :
     <instrument>---<DSM>---|                  |---<laptop>
                            |                  |
                            |                  |
    /Ethernet controlled\___|                  |___/Ethernet controlled\
    \ instr. (recorded) /   |                  |   \ instr.  (non-rec) /
               :            |                  |             :
               :            |                  |             :
    /Ethernet controlled\___|                  |___/Ethernet controlled\
    \ instr. (non-rec)  /   |                  |   \ instr.  (non-rec) /
                            |                  |
                            |---<TimeServer>---|
                            |                  |
                            |---<DataServer>---|
                            |        |         |
                            |        |         |
                            |    <SATCOM>      |