FAQ

Of course. Use the schemas you like, impove the ones you do not. If you like, your schemas can be included on this site.

We thought about allowing an inherent tree structure for parameters, algorithms, packages and instrumentation as opposed to our grouping mechanism. However we decided against it for two reasons:

• Referencing objects within a tree would require a path structure. While XML’s X-path might have helped within XML files, graphical user interfaces could have to display too much confusing data.
• No two people agree on a convention – some suggested tree structures were:
  • Aircaft1/Cabin/Chassis2/Module3/Channel4
  • Aircaft1/Engine2/Vendor3/Network4/DAU5/Slot6/Sensor7
  • Ground/Rack1/Shelf2/Card3/Bus4
  • Ground/Workstation1/Display2/Panel3/Dial4

We wanted to encourage the development of powerful algorithms and displays without each person worrying about what units to work in. Example 1) A group developing a display for indicating speed, altitude and yaw is free to work in Mach numbers, Feet and Celsius. The (admittedly eccentric) instrumentation vendor is free to work in Knots, Miles and Arc Minutes. Because all six units are referenced back (unknown to the user) to m/s, m and radians both the instrument and display will work together.

We wanted a mechanism that would allow data to be gathered via MIL-STD-1553 controllers, CAIS controllers, Ethernet nodes, and so on in a coherent manner. We wanted a mechanism that would extend that coherency to multiple flying platforms and to sampling on the ground. Finally we wanted a simple method of defining when formats or “packet lists” switch. It is important to note that equipment can run asynchronously with the acquisition cycle if monitored coherently with triple buffers.

If a 14-bit A/D value is transmitted as 12 bits and stored as 16 bits, we did not want to force the user to define the parameter three times with three different names. If the convention of transmitting the 12 MSBs and storing the 14 bits concatenated with two zeros as the LSBs is followed, the RangeMaximum and RangeMinimum values still apply. This works with offset binary or 2’s complement or sign + magnitude.

We wanted to apply the same rule as for offset binary as for sign+magnitude and twos-complement.

Modern data acquisition equipment tends to allow the anti-aliasing filter to change as the sample rate changes to maximize bandwidth while minimizing aliasing. Many companies have a convention or rule that specifies the filter cutoff as a fraction of the sample rate. An advantage of XidML is that vendors are free to write their own instrumentation schemas.

Use the Meters base unit if you want to measure in for example, mils, inches, feet, miles, nautical miles, mm, kms, and so on. You may have an output from an LVDT, odometer, “distance-from-waypoint” or GPS (altitude) instrument.

Use the Radians base unit if you want to measure angles in degrees, arc-minutes, arc-seconds and so on. You may have an output from a synchro or resolver or gyro or GPS (latitude, longitude) instrument.

The XidML convention is that Indexes start at 0 and Numbers start at 1 and either should be used if there is a risk of confusion. For example indexes are often used to point to bits within words or minor-frames within major-frames while numbers are often used to point to data-word within packets.

BitStream parameter typically indicates that these bits are part of a sequence of bits and that all bits must be stored (the parameter can not be truncated). Typical applications include:

• Video compression (MPEG4, MPEG2, H.261 etc).
• Audio compression (MPEG3 etc).
• Asynchronously Embedded PCM streams.

BitVector parameter typically indicates that these bits contain or are part of a larger parameter.Typical applications include:

• When sending two 8-bit parameters as one.
• When sending a single 32-bit parameters as two 16-bit parameters.

Boolean parameter typically is the output of an alarm algorithm. Typical applications include:

• The warning output of a preflight check.
• The error output of a continuous built-in-test check.