XidML


XidML is an open standard XML tailored for the aerospace industry. XidML describes how data is acquired, processed and packaged for transmission, storage or reproduction. The primary objective of XidML is to store and exchange complex instrumentation information between multiple vendors and user-groups gathering thousands of parameters.

Taxonomy

There are five major components within XidML – parameters, instruments, packages, links and algorithms – each with their own subset of metadata.

Parameters

Parameters describe all there is to know about a value being measured. Examples of the type of metadata associated with a parameter include
  • Name: uniquely identifies the parameter
  • DataFormat: format used to encode the sampled data - examples include Offset Binary and Binary Coded Decimal
  • Unit: unit of measurement of the parameter
  • LongDescription: detailed description of a parameter
  • ShortDescription: brief description of the parameter
  • SizeInBits: number of bits used to encode the sampled data
It is also possible to decompose a parameter into sub-parameters and to describe the meaning of each sub-parameter. For example, a 48-bit IRIG time parameter is typically broken up into High, Low and Micro time components.

Instruments

Instruments are the physical hardware used in data acquisition and describe how FTI devices are configured. All instruments share the following common metadata:
  • Name: uniquely identifies the parameter
  • Manufacturer: identifies the device manufacturer
  • PartReference: uniquely identifies the type of device
  • SerialNumber: uniquely identifies a specific device

Device configuration

Device configuration is described using zero or more settings. Settings are those values that affect the behavior of a device in an acquisition network. Settings consist of
  • Name: This is the name of the setting. Device vendors publish the allowed values for settings using XdefML. Examples of settings include Filter Cutoff and Excitation Amplitude
  • Value: This is the value associated with setting. Device vendors publish the allowed values and other value constraints using XdefML.

Packages

Packages describe how data is transmitted or stored. All packages must have globally unique names. Examples of transmission packages include IRIG-106 Chapter 4 PCM frame definitions, MIL-STD-1553 message definitions and Ethernet packet descriptions. An example storage format is the IRIG Chapter 10 data storage description.
All packages share the same common structure:
  • Properties: contains structural and other header information
  • Content: describes the payload content of a package – specifically, what parameters are transmitted, how often they are transmitted and where they are located within the package
  • Source: defines where a package originates
  • Destination: describes the destination of a package
All packages also include the following data:
  • Name: uniquely identifies a package
  • PackageRate: number of times the a package is sent or received a second

Algorithms

Algorithms describe how data is processed. Examples include polynomials used to linearize data and an algorithm used to extract a sub-set of bits from a parameter before transmission. All algorithms have a globally unique name.
  • Name: uniquely identifies an algorithm
  • Inputs: input parameters to an algorithm
  • Outputs: parameters output by an algorithm
The semantics of how an algorithm processes and generates data is described in the body of the algorithm.

Origins

The use of XML has become increasingly common in the flight test industry as a means of automating translation tasks and facilitating interoperability between systems. XidML was created with the aim of addressing the specific requirements encountered in aerospace applications. A XidML committee ensure vendor independence and ensures XidML remains relevant into the future.

Revisions

XidML has undergone a number of revisions in response to community feedback and requirements. It is currently at version 3.0.0 which introduced several major changes since version 2.4. These include fewer schemas for simplification, to make it easier to process by software and reduce the likelihood of future changes to the schema. Additionally, an optional complementary schema called XdefML has been added that facilitates instrument set-up and validation.