XidML (eXtensible Instrumentation Data exchange Mark-up Language) is an open standard XML tailored for the aerospace industry.[1] 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.
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 (expressed relative to SI units)
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 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 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 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
Links describe the physical connections between instruments. Examples of Links include an Ethernet connection between two networked devices and an RF link between an aircraft and a ground-station card in a PC. All links have a globally unique name.
Name: uniquely identifies a link
Type: defines the type of link e.g. Ethernet (an Ethernet connection) and ARINC-429 (a connection to an ARINC-429 bus)
Packages: describes what packages are being transmitted on a link in addition to the sequencing of this data on a link (optional)
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.
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.[2][3] 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.
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.
