On-Board Instrument Metadata Server Discussion

ABSTRACT

Given a number of instruments possessing health, status, and/or metadata packets on an airborne instrument payload network, establish requirements and discuss implementation issues for onboard web service(s) to manage such data.  

Overview

In June 2008 (action item 0806.7) we talked about having a server that could serve out variable/instrument meta-data in case the instrument maker couldn't provide the facility.  

Problem Definition

  1. You have a number of instruments broadcasting CSV packets aboard the aircraft.
  2. You have one or more programs which can access these packets for display or other processing needs, but the definition of the content of these packets needs to be managed as well.
  3. The ability for a client application (presumably a display application) to dynamically request the packet metadata is assumed.
  4. While it is understood that the instrument itself is the logical original source of this information, it is assumed that the instrument may not be the server of metadata information to requestors. A network service or daemon is proposed as a repository of this information.
  5. We thus envision a server as part of the aircraft infrastructure that manages this metadata.
    ----Example packets from instruments requiring metadata management:

Example CSV packets:

  • NOAA_SP2,,34.2,69.2,105.4
  • CPL1,20090219T22:08:54.000,107,74,57,74,75,67,67,62,84,...
  • WP3D,20080421T000654, 19.0000, 69.4613,-136.6085,1222.6000,-7.4400,...
  • HASR,20090116T205539,36.953,-75.431,4129.700,-3.713,-0.626,-2.896,-2.782,...
  • N255SA,2009-01-14T21:38:07Z,39.127834,-108.535667,1473.1,216.0,4.6
    ----

Q&A

Q: Should HDR (i.e. CSV packet description) be sent/broadcast periodically or only upon request?

  • A: Upon request became the final consensus.

Q: Should the server respond with UDP or is the response to the request a TCP oriented task? What about http?

  • A: the response to this query is a reasonably small file. TCP or http may be the most appropriate.
  • Using a TCP oriented approach would mean there could only be one server onboard. Eliminating instruments that could generate their own metadata. I am not opposed to this idea, just thought I would note it. I really like the simplicity of the http idea, we could just have .xml files in a predefined hierarchy and filenames. Display app only needs to know name of server. No software would need to be written. Something like wget(1) can be used to retrieve the metadata files based on the instruments CSV label/ID. --Chris

Q: If I have a display application, what do I use to name the variable?

  • A: Metadata should provide a variable name, possibly multiple names. Also units, default plot scale, and/or management strategies for missing values are warranted/needed for display apps.
    ----

Update From 03/09 Meeting

As a pilot project implement as text files retrievable via http. Use the CSV packet Identifier keyword as the filename. Add directory levels 'iwgadts':

  • No labels