MDL Examples

Table of Contents

  1. General Discussion
  2. Quick Start
    1. Defining the Test Mission
    2. Defining the Instrumentation Network
      1. Single instrumentation network for temperature measurement
      2. Multiple instrumentation networks sharing a measurement
      3. Instrumentation network for collecting two temperature measurements and two pressure measurements (TMATS Handbook)
    3. PCM
      1. Defining a PCM Frame in MDL
      2. Instrumentation network with PCM format for collecting two temperature measurements and two pressure measurements (TMATS Handbook)
      3. Instrumentation network with PCM format packaged into a single MDL message for collecting two temperature measurements and two pressure measurements (TMATS Handbook)
    4. Completing the MDL quick start example
      1. Packaging measurements the "MDL way"
      2. Adding network interfaces
      3. Adding a radio to the test article network
      4. Adding a recorder to the test article network
      5. Adding a ground station network
      6. Adding a recorder to the ground station network
      7. Signal conditioning
      8. Measurement requirements
  3. Test Missions
    1. TestMission Framework
    2. Radio Access Network (RAN)
    3. Test Article (TA) Network
    4. Network Topology
    5. Pulse Code Modulation (PCM) Backfill
  4. Radio Access Networks
    1. RANConfigurations [Recommended]
    2. Scheduling with Link Manager [Recommended]
    3. Scheduling without Link Manager
    4. Mission Service Level Profiles (MSLP) [Recommended]
    5. Mission Quality of Serivce (QoS)
    6. RadioAssociations [Recommended]
    7. Asset Associations
  5. Test Article Networks
    1. Measurements and DataStreams
      1. Analog Measurements and Transducers [Recommended]
      2. Measurements and DataProcessing
      3. Bandpass Measurement
      4. DataStream for Formatting PCM [Recommended]
      5. DataStream for Selecting ARINC 429 Bus Messages [Recommended]
      6. DataStream for ARINC 429 All Bus Capture [Recommended]
      7. DataStream for Selecting MIL-STD-1553 Bus Messages
      8. Non-First-Class Data Stream Example
    2. NetworkNodes and Devices
      1. DAU
      2. Recorder
      3. Switch Configured for Dynamic Routing
      4. Switch Configured for Static Routing
      5. Modules and Children
      6. Modules and SubModules
      7. Multiple Apps per NetworkNode
      8. Scanner
    3. Packages and Messages
      1. Packaging Analog Measurements [Recommended]
      2. Packaging Measurements
      3. Packaging Selected PCM Frames from DataStream [Recommended]
      4. Packaging All PCM Frames from DataStream [Recommended]
      5. Packaging PCM Major Frames
      6. Packaging Selected ARINC 429 Bus Messages from DataStream [Recommended]
      7. Packaging ARINC 429 All Bus Capture DataStream [Recommended]
      8. Packaging Selected ARINC 429 Measurements from DataStream
      9. Mapping 24-bit Measurement into 16-bit Fields [Recommended]
      10. Sending Analog Measurements in Messages [Recommended]
    4. Configuration Negotiation Protocol Steps
      1. MDL File after Retrieving Inventory from the Device
      2. MDL File to be Validated
      3. MDL File After Validation
  6. User Stories
    1. General User Stories
    2. Signal Characteristics User Stories
    3. Metadata User Stories
    4. RF Data Link User Stories
    5. Multiplex Waveform User Stories
    6. PCM Format User Stories
    7. Measurement User Stories
    8. Data Conversion User Stories
    9. Transmission User Stories
    10. Recorder User Stories
    11. Data Acquisition User Stories
    12. Signal Conditioning User Stories
    13. Temperature Measurement User Stories
    14. Bus Monitor User Stories
    15. Signal Conditioning User Stories
top

1. General Discussion

This appendix describes the collection of examples that have been released with the MDL schema. For cases where there are multiple examples for a concept the recommended approach has been tagged [Recommended]. In the sections that follow, each example listed in the table of contents is described using a table that provides the following information:


Along with the table, pictures or diagrams may also be provided to help the reader better visualize the example MDL file. It should be noted that the diagrams provided were valid when the example was released, and every effort has been made to keep them updated to the current version of the MDL schema.

Various conventions have been used throughout the examples. For example, TBD has been used as a placeholder when information is not known or the element is not a critical part of the example. It should also be noted that the value of "ID" attributes do not have meaning; however, they must be unique within an MDL instance document. Finally, XML comments in the example MDL files have not been widely used, but some examples do contain comments for key elements.

top

2. Quick Start

The purpose of this section is to give new users of MDL a quick introduction to some of the basic concepts. This section describes a high-level use case in which the user needs to collect four measurements: cabin temperature, engine temperature, left and right tire pressure. We incrementally build up an MDL file to illustrate the basic concepts. For those familiar with TMATS, this is similar to the example taken from the TMATS handbook. The intent is not to create complete MDL file, but to incrementally build up a realistic example MDL instance document. The subsequent sections will provide more depth for advanced users. The figure below illustrates the examples in this section. Each example in the figure includes a descriptive name and a reference to the test case that the example adresses. The test cases in the blue box will be of interest to those familiar with TMATS as they show how to take an existing PCM frame and store it in an MDL message. The remaining test cases are of general interest to those new to MDL.

The figure below organizes the use cases in responsibility lanes, indicating who is generally responsible for fulfilling or implementing the use case.


We begin with a basic definition of a test mission, which is at the top of the figure above. We extend the test mission in two ways: to define a PCM frame structure and to define an instrumentation network for collecting and conditioning a temperature measurement.

For the extension that packages the PCM frame in an MDL message, we evolve the example as follows:

For the extension that defines an instrumentation network for collecting and conditioning a temperature measurement (DAU, signal conditioning card, thermocouple), we evolve the example as follows:

The figures below show the measurements used in the examples. The first figure shows the four measurements arranged in a PCM frame. The second figure shows the same measurements arranged in an MDL message.

top

2.1 Defining the test mission

MDL File TC-4.xml
MDL Visualization TC4Diagram.svg
Date Introduced April 2016
Introduced with Schema Version v0.8.19
References User Stories Test Cases
Related Examples
Description The example shows the information needed for defining the test mission:
  • (Required) Define at least one test mission to include descriptive information for the test such as the name and a description of the test mission.
  • (Optional) A reference to a network is not technically required, but it is included for completeness
  • Define at least one network (a test mission should reference a network) with a name, description and network type (in this case a test article network)
  • Also for completeness, we include a measurement domain with a PCM data stream and 1553 Bus data stream

This is the minimal useful information to understand the basics of a test mission.

top

2.2 Defining the instrumentation network

2.2.1 Single instrumentation network for temperature measurement

MDL File TC-76.xml
MDL Visualization TC76Diagram.svg
Date Introduced April 2016
Introduced with Schema Version v0.8.19
References User Stories Test Cases
Related Examples
Description This example extends the basic definition of a test mission to include details of the test article network
  • Define a network node that contains the DAU and signal conditioning card. The DAU is associated with the network node via the TmNSApp and the DAU module. The DAU module is further defined as
    • A module with a single input port (for connecting to the signal conditioning card
    • A signal conditioning card with an input port (connecting to the thermocouple) and an output port (connecting to the DAU)
  • Define a thermocouple linked to the temperature measurement (this linkage is not part of the MDL) with an output port that connects to the input port of the DAU

In addition, a single measurement (engine temperature) is added that is conditioned by the signal conditioning card. This provides a simple end-to-end example of acquiring and conditioning a single measurement.

top

2.2.2 Multiple instrumentation networks sharing a measurement

MDL File TC-2a.xml
MDL Visualization TC2aDiagram.svg
Date Introduced April 2016
Introduced with Schema Version v0.8.19
References User Stories Test Cases
Related Examples
Description This example extends the basic instrumentation network to add a second test article network (identical to the first) and a ground station network. The purpose of this is to show how within a single MDL file, multiple networks can share the same measurement name since the measurement IDs are unique within an MDL file. There is no need to create the same measurement for each network.
top

2.2.3 Instrumentation network for collecting two temperature measurements and two pressure measurements (TMATS Handbook)

MDL File TC-1a.xml
MDL Visualization TC1aDiagram.svg
Date Introduced April 2016
Introduced with Schema Version v0.8.19
References User Stories Test Cases
Related Examples
Description This example extends the basic instrumentation network to add another temperature measurement (cabin temperature) and two pressure measurements (left tire pressure and right tire pressure). To support these additional measurements, another thermocouple and two pressure sensors are added, each with an output port that connects to a signal conditioning card. The original signal conditioning card for conditioning the engine temperature measurement only had one input port and one output port. We modified this card to have two input ports and two output ports. We added a similar signal conditioning card (two input ports and two output ports) for conditioning the pressure measurements. The outputs of the sensors are connected to the appropriate input of the signal conditioning cards and the outputs of the signal conditioning cards are connected to the DAUs.

The extensions for this example are shown in bold.

top

2.3 PCM

For those that are new to MDL, but familiar with PCM (specifically TMATS), this section walks through the definition of a PCM frame and packaging that frame into MDL messages.

2.3.1 Defining a PCM frame in MDL

MDL File TC-7.xml
MDL Visualization TC7Diagram.svg
Date Introduced April 2016
Introduced with Schema Version v0.8.19
References User Stories Test Cases
Related Examples
Description This example extends the basic definition of a test mission to the definition of a PCM frame using constructs from the TMATS schema; specifically the PCMFormatAttributesType. For more details, refer to the TMATS documentation.
top

2.3.2 Instrumentation network with PCM format for collecting two temperature measurements and two pressure measurements (TMATS Handbook)

MDL File TC-1b.xml
MDL Visualization TC1bDiagram.svg
Date Introduced April 2016
Introduced with Schema Version v0.8.19
References User Stories Test Cases
Related Examples
Description This example extends the instrumentation network example and defining a PCM frame example to store the measurements in the PCM frame.
top

2.3.3 Instrumentation network with PCM format packaged into a single MDL message for collecting two temperature measurements and two pressure measurements (TMATS Handbook)

MDL File TC-1c.xml
MDL Visualization TC1cDiagram.svg
Date Introduced April 2016
Introduced with Schema Version v0.8.19
References User Stories Test Cases
Related Examples
Description This example extends the instrumentation network example to store the PCM data in a single MDL message. The definition of the package points to the PCM frame where the measurements were placed. The DAU app contains a data source and points to the message.
top

2.4 Completing the MDL quick start example

This section illustrates MDL features for completing a simple MDL example instance document.

2.4.1 Packaging measurements the "MDL way"

MDL File TC-1d.xml
MDL Visualization TC1dNetworkDiagram.svg
Date Introduced April 2016
Introduced with Schema Version v0.8.19
References User Stories Test Cases
Related Examples
Description This example extends the instrumentation network example to add networking. A network port is added to the DAU. Also shown are the details of the message and package structure for placing the four measurements into an MDL message.
top

2.4.2 Adding network interfaces

MDL File TC-1e.xml
MDL Visualization TC1eDiagram.svg
Date Introduced April 2016
Introduced with Schema Version v0.8.19
References User Stories Test Cases
Related Examples
Description This example extends the basic messaging example to add a switch. A four-port switch is added to the test article network and the DAU is connected to the switch.

The extensions for this example are shown in bold.

top

2.4.3 Adding a radio to the test article network

MDL File TC-58.xml
MDL Visualization TC58Diagram.svg
Date Introduced April 2016
Introduced with Schema Version v0.8.19
References User Stories Test Cases
Related Examples
Description This example extends the networking example to add a radio to the test article network. A network node with a radio and network port is adeded to the test article network and the radio is connected to the switch.
top

2.4.4 Adding a recorder to the test article network

MDL File TC-60.xml
MDL Visualization TC60Diagram.svg
Date Introduced April 2016
Introduced with Schema Version v0.8.19
References User Stories Test Cases
Related Examples
Description This example extends the test article radio example to add a recorder to the test article network. A network node with a recorder and network port is added to the test article network and the recorder is connected to the switch. The recorder application has a data sink, which points to the message.
top

2.4.5 Adding a ground station network

MDL File TC-59.xml
MDL Visualization TC59Diagram.svg
Date Introduced April 2016
Introduced with Schema Version v0.8.19
References User Stories Test Cases
Related Examples
Description This example extends the test article recorder example to add a ground station with a radio and switch. The ground station radio is connected to the switch and the networks are linked via a radio link defined in the test mission.
top

2.4.6 Adding a recorder to the ground station network

MDL File TC-61.xml
MDL Visualization TC61Diagram.svg
Date Introduced April 2016
Introduced with Schema Version v0.8.19
References User Stories Test Cases
Related Examples
Description This example extends the ground station example to add a recorder to the ground station network. A network node with a recorder and network port is added to the ground station network and the recorder is connected to the switch. The recorder application has a data sink, which points to the message.
top

2.4.7 Signal conditioning

MDL File TC-68.xml
MDL Visualization TC68Diagram.svg
Date Introduced April 2016
Introduced with Schema Version v0.8.19
References User Stories Test Cases
Related Examples
Description This example illustrates the basic properties for signal conditioning (attenuation, filtering, excitation, etc.). The signal conditioning properties are specified on the output ports of the signal conditioniung cards.
top

2.4.8 Measurement requirements

MDL File TC-1f.xml
MDL Visualization TC1fDiagram.svg
Date Introduced April 2016
Introduced with Schema Version v0.8.19
References User Stories Test Cases
Related Examples
Description This example illustrates the basic information for measurement requirements (data length, sample rate, etc.).
top

3. Test Missions

3.1 TestMission Framework

MDL File TestMissionFramework.xml
MDL Visualization TestMissionFramework.svg
Date Introduced November 2010
Introduced with Schema Version v0.8.1
References Change Proposal
  • MDSWG-CP-000-Baseline
Related Examples
Description This is a standalone MDL Instance Document that provides some of the baseline elements that may be used to build more complex MDL Instance Documents.
  • TestMissions
    • List of individual test scenarios (several can be in the same instance document)
  • Units
  • MeasurementDomains
    • Measurements
    • PackageDefinitions
    • DataStructures
    • MessageDefinitions
    • DataStreams (Busses)
    • DataProcessing (transformations of data at various stages)
    • MeasurementGroups
    • MessageGroups
  • NetworkDomains
    • The infrastructure (nodes and network shape)
  • DSCPTable (DiffServe Code Point)
    • Quality of Service (QoS) parameters
top

3.2 Radio Access Network (RAN)

MDL File RadioAccessNetwork.xml
MDL Visualization RadioAccessNetwork.svg
Date Introduced December 2015
Introduced with Schema Version v0.8.19
References Standard
  • Chapter 22 - Internet Based Protocol Suite
  • Chapter 27 - RF Network Access Layer
  • Chapter 28 - RF Network Management

Change Proposal
  • MDSWG-CP-012-Network-Toplogy
  • MDSWG-CP-013-Communication-Link-Model
  • MDSWG-CP-014-Test-Description
  • MDSWG-CP-027-Serivce-Types-and-Quality-of-Service
Related Examples
Description The Radio Access Network (RAN) example MDL file is modeled after the figure below depicting three Ground Radios (GR) and a single Test Article Radio (TAR) and is a working example. The example MDL file defines the TestMissions, NetworkDomains, RANConfigurations, and DSCPTable.

The test mission defines the Mission Service Level Profiles (MSLP), the RadioLinks, and the AssetAssociations as required for the test. MSLPs are defined for each link to handle Quality of Service (QoS) IP routing across the RF link and the links are defined for radio to radio wireless RF communication. In this example file, the link definitions reference TmNSApps and radio groups for the wireless source and destination link addresses respectively. The AssetAssociations section links the TmNSApps defined in the NetworkDomains section that follows to the TestMission.

The NetworkDomains sections defines the required number of wired networks needed to support the TmNS Radios. In this example file, we have defined four networks; RAN1_Network, RAN2_Network, RAN3_Network, and TestArticle1_Network. There is one network for each radio. Each component is defined as a NetworkNode which provides high level descriptive information along with a TmNSApp section and an InternalStructure section. It is within the TmNSApp section that more detailed information such as the RoleID of the component and the component's specific configuration parameters are found. For example, a Radio will define its RF address and any RF Groups that it will subscribe to along with referencing the appropriate RANs configuration structure here. The InternalStructure section provides networking information in addition to other identifying information.

The RANConfigurations section provides RF transmission specific configuration parameters as well as radio groups available to be subscribed to by the radios defined as network nodes.

The DSCPTable section defines the DSCP values associated with each class of traffic for traffic routing purposes.
top

3.3 Test Article (TA) Network

MDL File TestArticleNetwork.xml
MDL Visualization TestArticleNetwork.svg
Date Introduced December 2015
Introduced with Schema Version v0.8.19
References Standard
  • Chapter 22 - Internet Based Protocol Suite
  • Chapter 24 - Message Formats
  • Chapter 26 - TmNS Data Transfer Protocols

Change Proposal
  • MDSWG-CP-002-Measurements-Requirements
  • MDSWG-CP-005-PCM-Stream-Format
  • MDSWG-CP-007-Package-Description
  • MDSWG-CP-015-Test-Article
  • MDSWG-CP-040-Rationale-for-Package-Structure-and-Mapping
Related Examples
Description The Test Article (TA) Network example MDL file is modeled after the figure below depicting three Data Acquisition Units (DAU), three Recorders, two Network Switches, and a Ground Test Article Manager GTAM) and is a working example. The example MDL file defines the Units, MeasurementDomains, NetworkDomains, and DSCPTable.

The Units section defines the derived units used within this file.

The MeasurementDomain defines the analog and bus Measurements, PackageDefinitions descriptions, MessageDefinitions, DataStreams, and DataProcessing required for this test. Measurements have been defined for transducers such as thermocouples and accelerometers, and for busses such as ARINC 429. Along with the Measurements, DataProcessing have been defined to describe the conversions from Instrumentation Units (IU) to Engineering Units (EU). Packages have been defined for TmNS Data Messages (TDM) and for PCM. The Message definitions include multicast address information and references to the packages that will be sent. DataStreams have been defined for both ARINC 429 and PCM.

The NetworksDomain section defines a single TA Network named Test Article Network. This network contains all of the components in the TA Network. Each component is defined as a NetworkNode which provides high level descriptive information along with a TmNSApp section and an InternalStructure section. It is within the TmNSApp section that more detailed information such as the RoleID of the component and the component's specific configuration parameters are found. For example, a DAU references the message definitions that it will publish. The DAU's InternalStructure lists the modules that comprise the hardware configuration of the DAU.

NOTE: PortMappings, describing the Network Switch connections, have not been defined for this example. Refer to the Network Topology for an example showing Network Switch connections.

The DSCPTable section defines the DSCP values associated with each class of traffic for traffic routing purposes.
top

3.4 Network Topology

MDL File NetworkTopology.xml
MDL Visualization NetworkTopology.svg
Date Introduced November 2010
Introduced with Schema Version v0.8.1
References Standard
  • Chapter 22 - Internet Based Protocol Suite

Change Proposal
  • MDSWG-CP-012-Network-Toplogy
Related Examples
Description This example includes multiple NetworkNodes and shows how PortMappings can be used to connect the NetworkNodes and form a network.
top

3.5 Pulse Code Modulation (PCM) Backfill

MDL File PCMBackfill.xml
MDL Visualization PCMBackfill.svg
Date Introduced May 2011
Introduced with Schema Version v0.8.4
References Standard
  • Chapter 24 - Message Formats

Change Proposal
  • MDSWG-CP-005-PCM-Stream-Format
  • MDSWG-CP-007-Package-Description
Related Examples
Description This example includes a DAU (not pictured) that creates a PCM stream. The PCM stream is sent to two different boxes: SST transmitter and PCM gateway. The SST transmitter sends PCM to the ground station, while the PCM gateway packages the PCM frames into TmNS messages and transmits them on the network.

The TmNS recorder on the TA records the TmNS messages containing the PCM frames.

The ground station detects PCM dropouts of the SST link and requests the missing frames of the SST transmitted PCM stream from the recorder via the recorded TmNS messages from the PCM gateway.

The key elements here are the decommutation of the SST PCM and being able to determine the MDID of the TmNS message that contains the SST transmitted PCM data that is recorded on the TA recorder, as well as package information, etc.
top

4. Radio Access Networks

4.1 RANConfigurations [Recommended]

MDL File RANConfigurations.xml
MDL Visualization RANConfigurations.svg
Date Introduced February 2016
Introduced with Schema Version v0.8.19
References Standard
  • Chapter 27 - RF Network Access Layer
  • Chapter 28 - RF Network Management

Change Proposal
  • MDSWG-CP-013-Communication-Link-Model
Related Examples Scheduling with Link Manager [Recommended]
Scheduling without Link Manager
Description This example depicts a single RANConfiguration that contains two Radio Groups. The RANConfiguration provides RF specific configuration parameters that are required for RF transmissions and receipts between multiple radios. Additionally, all radio groups available to be subscribed to by the radios are defined here.
top

4.2 Scheduling with Link Manager [Recommended]

MDL File DynamicScheduling.xml
MDL Visualization DynamicScheduling.svg
Date Introduced February 2016
Introduced with Schema Version v0.8.19
References Standard
  • Chapter 27 - RF Network Access Layer
  • Chapter 28 - RF Network Management

Change Proposal
  • MDSWG-CP-012-Network-Toplogy
  • MDSWG-CP-013-Communication-Link-Model
Related Examples Mission Service Level Profiles [Recommended]
Radio Associations [Recommended]
Description This example depicts a Link Manager (LM) NetworkNode, a Ground Radio (GR) NetworkNode, and Test Article Radio (TAR) NetworkNode. The required RadioLinks for radio-to-radio RF communication are included as well. Radio NetworkNodes and RadioLinks in MDL are cross dependent so they must be defined together.

The LM, GR, and TAR are defined as NetworkNodes. A NetworkNode provides generic high level descriptive information along with a more detailed information in the TmNSApp element and an InternalStructure element.

It is within the TmNSApp element that information such as the RoleID of the component and the component's specific configuration parameters are found. For example, a Radio will define its RF address, any RF Groups that it will subscribe to, and its LinkAgent ListeningPort while an LM will reference the radios that it is to manage. Both radios and the LM will reference the appropriate RANConfiguration element.

The InternalStructure element provides networking information in addition to other identifying information. Radios will additionally define routes here which require a reference ID to a specific RadioLink.

There are two links defined to support bi-directional communication between the two radios. The link definitions reference TmNSApps and RadioGroups for the wireless source and destination link addresses respectively. Any RadioGroup that is referenced as a destination address for a RadioLink must be referenced by at least one radio NetworkNode as a JoinRadioGroupRef otherwise the transmissions will not be received. Additional link configuration parameters are set for the specific links here as well.

Radio NetworkNodes, LM NetworkNodes, and RadioLinks require either references to or references defined in RANConfigurations and DSCPTable.
top

4.3 Scheduling without Link Manager

MDL File StandaloneScheduling.xml
MDL Visualization StandaloneScheduling.svg
Date Introduced February 2016
Introduced with Schema Version v0.8.19
References Standard
  • Chapter 27 - RF Network Access Layer
  • Chapter 28 - RF Network Management

Change Proposal
  • MDSWG-CP-012-Network-Toplogy
  • MDSWG-CP-013-Communication-Link-Model
Related Examples
Description This example depicts a Ground Radio (GR) NetworkNode and Test Article Radio (TAR) NetworkNode. The required RadioLinks for radio-to-radio RF communication are included as well. Radio NetworkNodes and RadioLinks in MDL are cross dependent so they must be defined together.

The GR and TAR are defined as NetworkNodes. A NetworkNode provides generic high level descriptive information along with a more detailed information in the TmNSApp element and an InternalStructure element.

It is within the TmNSApp element that information such as the RoleID of the component and the component's specific configuration parameters are found. For example, a Radio will define its RF address, any RF Groups that it will subscribe to, and its LinkAgent ListeningPort.

The InternalStructure element provides networking information in addition to other identifying information. Radios will additionally define routes here which require a reference ID to a specific RadioLink.
top

4.4 Mission Service Level Profiles (MSLP) [Recommended]

MDL File MissionServiceLevelProfiles.xml
MDL Visualization MissionServiceLevelProfiles.svg
Date Introduced February 2016
Introduced with Schema Version v0.8.19
References Standard
  • Chapter 22 - Internet Based Protocol Suite
  • Chapter 27 - RF Network Access Layer
  • Chapter 28 - RF Network Management

Change Proposal
  • MDSWG-CP-012-Network-Toplogy
  • MDSWG-CP-013-Communication-Link-Model
  • MDSWG-CP-027-Serivce-Types-and-Quality-of-Service
Related Examples Radio Access Network (RAN)
Description This example depicts a Link Manager (LM) NetworkNode, a Ground Radio (GR) NetworkNode, and Test Article Radio (TAR) NetworkNode. The required RadioLinks for radio-to-radio RF communication are included as well, and for each link a unique Mission Service Level Profile (MSLP) is defined.

The LM, GR, TAR, and associated links were taken from the Scheduling example, which can be referenced for additional details related to those elements.

At a high level, MSLPs are defined for each link to handle Quality of Service (QoS) IP routing across the RF links that are defined for radio to radio wireless RF communication. Each MSLP defines a specific set of rules for IP routing that are applied to the RadioLink that is referenced.

MSLP require RadioLinks to be defined and therefore inherit any requirements of RadioLinks.
top

4.5 Mission QoS

MDL File MissionQoS.xml
MDL Visualization MissionQoS.svg
Date Introduced October 2011
Introduced with Schema Version v0.8.10
References Standard
  • Chapter 22 - Internet Based Protocol Suite

Change Proposal
  • MDSWG-CP-027-Serivce-Types-and-Quality-of-Service
Related Examples
Description This example includes mission service level profiles for an example uplink minimal queue (<MissionSLP ID="TA_MissionSLP_3">) and an example downlink Joint Strike Fighter (JSF) flutter test (<MissionSLP ID="TA_MissionSLP_1">) and demonstrates how they are used by radio links. These profiles define the queueing disciplines and priorities for the radio links. Also shown are the radio links, network nodes, and DSCP table.
top

4.6 Radio Associations [Recommended]

MDL File RadioAssociations.xml
MDL Visualization RadioAssociations.svg
Date Introduced February 2016
Introduced with Schema Version v0.8.19
References Standard
  • Chapter 27 - RF Network Access Layer
  • Chapter 28 - RF Network Management

Change Proposal
  • MDSWG-CP-012-Network-Toplogy
  • MDSWG-CP-013-Communication-Link-Model
  • MDSWG-CP-014-Test-Description
Related Examples Radio Access Network (RAN)
Description This example depicts a Link Manager (LM) NetworkNode, a Ground Radio (GR) NetworkNode, and Test Article Radio (TAR) NetworkNode. The required RadioLinks for radio-to-radio RF communication are included and each radio is referenced in the RadioAssoc definition.

The LM, GR, TAR, and associated links were taken from the Scheduling example which can be referenced for additional details related to those elements.

The RadioAssoc definition is a more detailed association that falls within AssetAssociations. The purpose is to define which radios are being used in the test configuration by referencing the radio NetworkNodes using their TmNSApp IDs.

RadioAssoc require radio NetworkNodes to be defined and therefore inherit any requirements of radio NetworkNodes.
top

4.7 Asset Associations

MDL File AssetAssociations.xml
MDL Visualization AssetAssociations.svg
Date Introduced October 2011
Introduced with Schema Version v0.8.10
References Change Proposal
  • MDSWG-CP-014-Test-Description
Related Examples
Description This example shows how to create SST associations.

SST Physical Associations
  • Each Auto Tracking Antenna has an associated Antenna Control Unit (ACU)
    • ACU is physically connected to antenna via a cable (i.e., a physical association)
  • Each ACU has an associated SST Receiver used for tracking
    • SST Receiver output is physically connected to ACU via a cable (i.e., a physical association)
    • For tracking purposes, the ACU is calibrated to the SST Receiver
  • Each Auto Tracking Antenna is associated with one or more SST Receivers
    • Antenna output(s) are physically connected to one or more SST receivers via a cable (and possibly via a patch panel)
  • All of these devices are also physically associated with an Antenna Site

SST Logical Associations
  • SST Transmitter and SST Receivers are logically associated with a single SST frequency
    • SST Transmitter 1 and Receiver 1 are associated with channel 30 (1800MHz) via SSTAssoc SSTA1
    • SST Transmitter 2 and Receiver 2 are associated with channel 31 (1850MHz) via SSTAssoc SSTA2
  • Logical associations assists SST Manager with executing "change SST Freq from X to Z"
  • Antennas, ACUs, SST Receivers, and SST Transmitters are also logically associated with a single mission (i.e., mission SST assets)
top

5. Test Article Networks

5.1 Measurements and DataStreams

5.1.1 Analog Measurements and Transducers [Recommended]

MDL File AnalogMeasurementsAndTransducers.xml
MDL Visualization AnalogMeasurementsAndTransducers.svg
Date Introduced February 2016
Introduced with Schema Version v0.8.19
References Change Proposal
  • MDSWG-CP-002-Measurements-Requirements
Related Examples Packaging Analog Measurements [Recommended]
Description This example covers the use of analog measurements and transducers, from creating the measurements and their data operations for Counts to EU conversions, through the devices used to capture the measurements, and how they are attached to the DAUs.
top

5.1.2 Measurements and DataProcessing

MDL File MeasurementsAndDataProcessing.xml
MDL Visualization MeasurementsAndDataProcessing.svg
Date Introduced November 2010
Introduced with Schema Version v0.8.1
References Change Proposal
  • MDSWG-CP-002-Measurements-Requirements
Related Examples Packaging Measurements
Description This example includes a measurement (<Measurement ID="GearVibMeas">) and demonstrates how it is mapped from a transducer (<Device ID="GearVibTransducer">) port to a DAU (<NetworkNode ID="Dau1">) port. Also shown is the data processing (<DataOperation ID="GearVibCountsToGsConversion">) that represents the conversion from Counts to Volts.
top

5.1.3 Bandpass Measurement

MDL File BandpassMeasurement.xml
MDL Visualization BandpassMeasurement.svg
Date Introduced February 2013
Introduced with Schema Version v0.8.14
References Standard
  • Chapter 26 - TmNS Data Transfer Protocols
Related Examples
Description This examples shows how to create a measurement with Bandpass analog properties.
top

5.1.4 DataStream for Formatting PCM [Recommended]

MDL File DataStreamForFormattingPCM.xml
MDL Visualization DataStreamForFormattingPCM.svg
Date Introduced February 2016
Introduced with Schema Version v0.8.19
References Change Proposal
  • MDSWG-CP-005-PCM-Stream-Format
  • MDSWG-CP-024-Serial-Bit-Stream-Package
Related Examples Packaging Selected PCM Frames from DataStream [Recommended]
Packaging All PCM Frames from DataStream [Recommended]
Description This example shows how to use a DataStream for PCM output. The DataStream contains a PCMDataLink element that uses TMATS to describe the PCM format.
top

5.1.5 DataStream for Selecting ARINC 429 Bus Messages [Recommended]

MDL File DataStreamForSelectingARINC429BusMessages.xml
MDL Visualization DataStreamForSelectingARINC429BusMessages.svg
Date Introduced February 2016
Introduced with Schema Version v0.8.19
References Standard
  • Chapter 24 - Message Formats
  • Chapter 26 - TmNS Data Transfer Protocols

Change Proposal
  • MDSWG-CP-001-Bus-Catalog
  • MDSWG-CP-016-Avionics-Busses
Related Examples Packaging Selected ARINC 429 Bus Messages from DataStream [Recommended]
Description This example shows how to use a DataStream to capture selected ARINC 429 bus messages and extract the data field from the message using measurements.
top

5.1.6 DataStream for ARINC 429 All Bus Capture [Recommended]

MDL File DataStreamForARINC429AllBusCapture.xml
MDL Visualization DataStreamForARINC429AllBusCapture.svg
Date Introduced May 2014
Introduced with Schema Version v0.8.17
References Standard
  • Chapter 24 - Message Formats
  • Chapter 26 - TmNS Data Transfer Protocols

Change Proposal
  • MDSWG-CP-001-Bus-Catalog
  • MDSWG-CP-016-Avionics-Busses
Related Examples Packaging ARINC 429 All Bus Capture DataStream [Recommended]
Description This example shows how to use a DataStream to capture all ARINC 429 bus messages. The five measurements defined will be reused for each captured bus message.
top

5.1.7 DataStream for Selecting MIL-STD-1553 Bus Messages

MDL File DataStreamForSelectingMILSTD1553BusMessages.xml
MDL Visualization DataStreamForSelectingMILSTD1553BusMessages.svg
Date Introduced May 2011
Introduced with Schema Version v0.8.3
References Standard
  • Chapter 24 - Message Formats
  • Chapter 26 - TmNS Data Transfer Protocols

Change Proposal
  • MDSWG-CP-001-Bus-Catalog
  • MDSWG-CP-016-Avionics-Busses
Related Examples
Description This example shows how to use a DataStream to capture selected MIL-STD-1553 bus messages.
top

5.1.8 Non-First-Class Data Stream Example

MDL File NonFirstClassDataStream.xml
MDL Visualization NonFirstClassDataStream.svg
Date Introduced November 2013
Introduced with Schema Version v0.8.16
References Change Proposal
  • MDSWG-CP-007-Package-Description
Related Examples
Description This example uses the GenericDataStreamMessage to show how to describe a data stream that is not explicitly supported in MDL. The Chapter 11 example data stream is defined in the <DataStream ID="ds-001"> element.
top

5.2 Network Nodes and Devices

5.2.1 DAU

MDL File DAU.xml
MDL Visualization DAU.svg
Date Introduced June 2016
Introduced with Schema Version v0.8.20
References
Related Examples
Description This example shows how to describe a DAU NetworkNode in MDL. The described DAU is composed of 5 modules (Module 102, Module 1, Module 2, Module 3 and Module 4). In addition, this example shows data processing on a DAU. It describes a 10-sample moving average of a measurement and define an IIR-type recursive operation. The average Measurement is input and result of the function.
top

5.2.2 Recorder

MDL File Recorder.xml
MDL Visualization Recorder.svg
Date Introduced June 2016
Introduced with Schema Version v0.8.20
References
Related Examples
Description This example shows how to describe a NetworkNode with a Recorder in MDL. The Recorder has a TmNSRCDataSource element containing a list of MessageDefinitionRef, PackageDefinitionRef and MeasurementRef elements that describe the messages, packages and measurements that the Recorder is instructed to generate. The Recorder has a TmNSRCDataSink element that contains a list of MessageDefinitionRef that described the messages the Recorder is instructed to collect.
top

5.2.3 Switch Configured for Dynamic Routing

MDL File SwitchConfiguredDynamicRouting.xml
MDL Visualization SwitchConfiguredDynamicRouting.svg
Date Introduced June 2016
Introduced with Schema Version v0.8.20
References
Related Examples
Description This example shows how to describe a switch configured for dynamic multicast routing mode in MDL. This examples implements the TmNS Network Fabric Device System Management interface and more particularly how to describe a dynamic mode of multicast routing.
top

5.2.4 Switch Configured for Static Routing

MDL File SwitchConfiguredStaticRouting.xml
MDL Visualization SwitchConfiguredStaticRouting.svg
Date Introduced June 2016
Introduced with Schema Version v0.8.20
References
Related Examples
Description This example shows how to describe a switch configured for static multicast routing mode in MDL. This examples implements the TmNS Network Fabric Device System Management interface and more particularly how to describe a static mode of multicast routing.
top

5.2.5 Modules and Children

MDL File ModulesAndChildren.xml
MDL Visualization ModulesAndChildren.svg
Date Introduced November 2014
Introduced with Schema Version v0.8.18
References
Related Examples
Description This example includes a NetworkNode that is composed of 4 modules (CPU, Analog, 2 Bus Controllers) and demonstrates the Parent/Child relationships between the various Modules and Devices in the multi-bus system. The Children references indicate that the NetworkNode is responsible for configuring and/or controlling the Modules and Devices that are included in the Children tree. Also shown is the composition of Devices by multiple DeviceModules.

NOTE: NetworkNodes and Devices represent physical components. NetworkNodes have one or more NetworkInterfaces. Devices do not have NetworkInterfaces.
top

5.2.6 Modules and SubModules

MDL File ModulesAndSubModules.xml
MDL Visualization ModulesAndSubModules.svg
Date Introduced December 2016
Introduced with Schema Version v0.9.0
References
Related Examples
Description This example includes a NetworkNode that is composed of one module named "Chassis". This module is composed of 2 sub-modules. The Module is a container of sub-module(s) in the hierarchy. The sub-module represent a physical sub-component attached to the module such as a daughter-card. Sub-modules are always contained in a module. We never need to go deeper than two level deep.

top

5.2.6 Multiple Apps per Network Node

MDL File MultipleAppsPerNetworkNode.xml
MDL Visualization MultipleAppsPerNetworkNode.svg
Date Introduced May 2011
Introduced with Schema Version v0.8.5
References
Related Examples
Description This example shows the one-to-many relationship between a NetworkNode and TmNSApps (TMAs). NetworkNodes are physical devices and contain a list of TmNSApps that run on the NetworkNode. The RoleID uniquely identifies a TmNSApp (not the NetworkNode). The TmNSApp contains the RoleID, TmNS specializations, and the SNMPInterface description.

Configuring a NetworkNode (possible workflow)
  • TmNSApp(s) loaded on the NetworkNode and configured with RoleID
    • Software is installed
    • Startup script runs
      • Adapter (if present) starts first
      • Other TMAs following
    • RoleID(s) gets set (perhaps from command-line option in script)
    • System Management (SM) interface starts
  • TMA (like a DAU) may be able to determine details of NetworkNode on which it runs (e.g. Manufacturer, InventoryID, Model, SerialIdentifier)
  • TMA may be configured with Network Name through SM interface or by other means (e.g. startup script)
  • When commanded through SM interface, TMA reads MDL file and locates configuration based on known items
top

5.2.7 Scanner

MDL File Scanner.xml
MDL Visualization Scanner.svg
Date Introduced January 2017
Introduced with Schema Version v0.9.0
References
Related Examples
Description This example shows how to implement a module that connects to scanner devices using vendor extensions.

top

5.3 Packages and Messages

5.3.1 Packaging Analog Measurements [Recommended]

MDL File PackagingAnalogMeasurements.xml
MDL Visualization PackagingAnalogMeasurements.svg
Date Introduced February 2016
Introduced with Schema Version v0.8.19
References Standard
  • Chapter 24 - Message Formats

Change Proposal
  • MDSWG-CP-007-Package-Description
Related Examples Sending Analog Measurements in Messages [Recommended]
Description This example shows how to package analog measurements. A PackageStructure is defined as a reusable container to describe the shape of the outgoing package data, and a set of PackageDefinitions containing references to the desired analog measurements then provide populated instances of that PackageStructure.
top

5.3.2 Packaging Measurements

MDL File PackagingMeasurements.xml
MDL Visualization PackagingMeasurements.svg
Date Introduced May 2011
Introduced with Schema Version v0.8.3
References Standard
  • Chapter 24 - Message Formats

Change Proposal
  • MDSWG-CP-007-Package-Description
Related Examples
Description This example extends the Measurements and DataProcessing example by adding packages and messages. Refer to <PackageDefinition ID="PackageDefinition1"> for an example of packaging an analog measurement.
top

5.3.3 Packaging Selected PCM Frames from DataStream [Recommended]

MDL File PackagingSelectedPCMFramesFromDataStream.xml
MDL Visualization PackagingSelectedPCMFramesFromDataStream.svg
Date Introduced November 2013
Introduced with Schema Version v0.8.16
References Standard
  • Chapter 24 - Message Formats

Change Proposal
  • MDSWG-CP-005-PCM-Stream-Format
  • MDSWG-CP-024-Serial-Bit-Stream-Package
Related Examples Test Article (TA) Network
Description Selected PCM Minor Frames
  • PackageDefinition contains a DataStreamRef and a list of MinorFrame identifiers
  • Describes a Package containing a specified ordering of PCM minor frames from a TMATS-described PCM stream

NOTE: PCM can be described using TMATS or GenericDataStream.
top

5.3.4 Packaging All PCM Frames from DataStream [Recommended]

MDL File PackagingAllPCMFramesFromDataStream.xml
MDL Visualization PackagingAllPCMFramesFromDataStream.svg
Date Introduced November 2013
Introduced with Schema Version v0.8.16
References Standard
  • Chapter 24 - Message Formats

Change Proposal
  • MDSWG-CP-005-PCM-Stream-Format
  • MDSWG-CP-024-Serial-Bit-Stream-Package
Related Examples Test Article (TA) Network
Description Entire PCM DataStream
  • PackageDefinition includes a DataStreamRef
  • Package contains any/all frames/minor frames from TMATS-described PCM stream
  • Package contents are described by referenced DataStream

NOTE: PCM can be described using TMATS or GenericDataStream.
top

5.3.5 Packaging PCM Major Frames

MDL File PackagingPCMMajorFrames.xml
MDL Visualization PackagingPCMMajorFrames.svg
Date Introduced May 2011
Introduced with Schema Version v0.8.4
References Standard
  • Chapter 24 - Message Formats

Change Proposal
  • MDSWG-CP-005-PCM-Stream-Format
  • MDSWG-CP-007-Package-Description
Related Examples
Description This example describes how to use TMATS to package the PCM frames shown in the figure.
top

5.3.6 Packaging Selected ARINC 429 Bus Messages from DataStream [Recommended]

MDL File PackagingSelectedARINC429BusMessagesFromDataStream.xml
MDL Visualization PackagingSelectedARINC429BusMessagesFromDataStream.svg
Date Introduced November 2013
Introduced with Schema Version v0.8.16
References Standard
  • Chapter 24 - Message Formats

Change Proposal
  • MDSWG-CP-007-Package-Description
  • MDSWG-CP-016-Avionics-Busses
Related Examples Test Article (TA) Network
Description Selected Bus Messages
  • PackageDefinition contains a DataStreamRef and a list of DataStreamMessageRefs
  • Describes a Package containing one or more MIL-STD-1553 Messages, ARINC 429 Messages, or Generic Data Stream Messages in a specified order
top

5.3.7 Packaging ARINC 429 All Bus Capture DataStream [Recommended]

MDL File PackagingARINC429AllBusCaptureDataStream.xml
MDL Visualization PackagingARINC429AllBusCaptureDataStream.svg
Date Introduced November 2013
Introduced with Schema Version v0.8.16
References Standard
  • Chapter 24 - Message Formats

Change Proposal
  • MDSWG-CP-007-Package-Description
  • MDSWG-CP-016-Avionics-Busses
Related Examples Test Article (TA) Network
Description Entire Bus DataStream
  • PackageDefinition includes a DataStreamRef
  • Package contains any/all messages from MIL-STD-1553, ARINC 429, or generic data stream
  • Package contents are described by referenced DataStream
top

5.3.8 Packaging Selected ARINC 429 Measurements from DataStream

MDL File PackagingSelectedARINC429MeasurementsFromDataStream.xml
MDL Visualization PackagingSelectedARINC429MeasurementsFromDataStream.svg
Date Introduced November 2014
Introduced with Schema Version v0.8.18
References Standard
  • Chapter 24 - Message Formats

Change Proposal
  • MDSWG-CP-001-Bus-Catalog
  • MDSWG-CP-016-Avionics-Busses
Related Examples
Description Individual DataStream Measurements
  • PackageStructure describes the field sizes and locations
  • DataMap describes the mapping of individual Measuremens to the data fields
    • Used when message formats are transposed between capture and packaging
  • Applicable to MIL-STD-1553, ARINC 429, PCM Streams, and GenericDataStreams
top

5.3.9 Mapping 24-bit Measurement into 16-bit Fields [Recommended]

MDL File Mapping24BitMeasurementInto16BitFields.xml
MDL Visualization Mapping24BitMeasurementInto16BitFields.svg
Date Introduced May 2011
Introduced with Schema Version v0.8.3
References Change Proposal
  • MDSWG-CP-040-Rationale-for-Package-Structure-and-Mapping
Related Examples Test Article (TA) Network
Description This example provides a description for encoding a 24-bit measurement into adjacent 16-bit fields.

When packaging a 24-bit measurement into a PackageStructure with 16-bit data fields, one can use syllables and bit masking to arrange the measurement to fit into multiple data fields. First, the SyllableMask will be applied to the measurement. Then, the SyllableStartBit and the DataWordOffset will be used to determine the location and the bits that make up the syllable, pulled from the masked measurement. Finally, the DataWordOffset determines the position of the syllable in the data word.

In the decoding of the package, the process will be run in reverse. First, the DataWordOffset will be used to determine which bits of the data word make up the target syllable. Then, the SyllableStartBit will be used to determine where the SyllableMask will be applied. Finally, the masking to produce the pieces of the measurement will be applied, and all the syllables that make up the data word will be bitwise ORed together to produce the measurement's original value.
top

5.3.10 Sending Analog Measurements in Messages [Recommended]

MDL File SendingAnalogMeasurementsInMessages.xml
MDL Visualization SendingAnalogMeasurementsInMessages.svg
Date Introduced February 2016
Introduced with Schema Version v0.8.19
References Standard
  • Chapter 24 - Message Formats
Related Examples Test Article (TA) Network
Description This example shows how to use Messages to send the assembled packages. Two possibilities are shown: the use of one separate message for each of the three measurements, and the use of one message which contains a set of the desired packages.
top

5.5 Negotiation Protocol Steps

5.5.1 Retrieve Inventory from the Device

MDL File TestArticleNetworkInventory.xml
MDL Visualization TestArticleNetworkInventory.svg
Date Introduced December 2016
Introduced with Schema Version v0.9.0
References Standard
  • Chapter 25 - Management Resources
Description This example shows an example of an MDL file after requesting the inventory from the data aquisition device.
top

5.5.2 MDL File to be validated.

MDL File TestArticleNetworkToBeValidated.xml
MDL Visualization TestArticleNetworkToBeValidated.svg
Date Introduced December 2016
Introduced with Schema Version v0.9.0
References Standard
  • Chapter 25 - Management Resources
Description This example shows an MDL file before it is validated by the data aquisition device.
top

5.5.3 MDL File After validation.

MDL File TestArticleNetwork.xml
MDL Visualization TestArticleNetwork.svg
Date Introduced December 2016
Introduced with Schema Version v0.9.0
References Standard
  • Chapter 25 - Management Resources
Related Examples Test Article (TA) Network
Description This example shows an example of an MDL file after validation with the data aquisition device. Refer to lines 14639, 14656, and 14673 to see an example of a GenericParameter that was added after a 303 Redirect error. This example also shows the data processing in line 9653 to 9677. If the DAU cannot do the conversion then the data procession and output measurement is dropped from the file (refer to Test Article (TA) Network for an example on how the file looks like after validation)
top

6. User Stories

This section documents MDL requirements in the form of user stories that the MDL schema should satisfy. To cover the requirements, we include three pieces of information:


The relationships between user stories, instance documents, and test cases are illustrated in the figure below:
We capture schema requirements using user stories. User stories are used in the agile software development process to capture the function that a system is to perform. Since the MDL schema is intended to capture the function that a telemetry system is intended to perform, we feel that user stories are a simple and concise way to capture requirements. The general format of a user story is:

top

6.1 General User Stories

User Story Test Case Instance Document Line Nos.
US-1 As a test engineer, I want to be able to fully describe the data being transmitted from, or recorded on, an item under test so that I can monitor in-flight progress and process and assess the test result. To some extend, all test cases in this section contribute to fulfillment of this user story. For a specific example, we will demonstrate the example used in the TMATS Handbook.

TC-1a Instrumentation network to collect two temperature and two pressure measurements
Details
  • Define four MDL measurements (two temperature, two pressure)
  • Define a DAU with two signal conditioning cards
  • Define two thermocouples and two pressure sensors
  • Connect the sensors to the signal conditioning cards and the signal conditioning cards to the DAU


TC-1b PCM frame definition for two temperature and two pressure measurements
Details
  • Define a PCM frame for the four measurements (according to the TMATS handbook)


TC-1c PCM frame definition for two temperature and two pressure measurements packaged to an MDL message
Details
  • Define a MDL package linked to the PCM data stream
  • Define an MDL message that links to the package that contains the PCM data
  • Define a DSCP level for the message
  • Define a data source on the DAU that links to the MDL message


TC-1d Two temperature and two pressure measurements packaged to an MDL message
Details
  • Define units for 2 bytes
  • Define a package structure for the message: left tire pressure, engine temperature, right tire pressure, left tire pressure, cabin temperature, right tire pressure. All fields are two bytes in width
    • Define a package data field at position #2 (offset 1) for engine temperature
    • Define a package data field at position #5 (offset 4) for cabin temperature
    • Define a package data field set at positions #1 (offset 0) and #4 (offset 3)for left tire pressure
    • Define a package data field set at positions #3 (offset 2) and #6 (offset 5)for right tire pressure
  • Define a package definition that links to the package structure above, with data word to field / field set mappings for each measurement
  • Define an MDL message that links to the package definition
  • Define a DSCP level for the message
  • Define a data source on the DAU that links to the MDL message
NOTE that the data stream that defines the PCM is no longer needed, so it is removed.

TC-1e Network definition
Details
  • Define a network interface for the DAU
  • Add a switch to the test article network
  • Connect the DAU to the switch via an ethernet connection


TC-1f Measurement requirements
Details
  • Define a data length for all measurements
  • Define a sample rate for all measurements
 For TC-1a Instrumentation network for collecting two temperature measurements and two pressure measurements (TMATS Handbook)

For TC-1b Instrumentation network with PCM format for collecting two temperature measurements and two pressure measurements (TMATS Handbook)

For TC-1c Instrumentation network with PCM format packaged into a single MDL message for collecting two temperature measurements and two pressure measurements (TMATS Handbook)

For TC-1d Packaging measurements the "MDL way"

For TC-1e Adding network interfaces

For TC-1f Measurement requirements 		N/A
US-2 As a test engineer, I want to set up a combined mission of two aircraft that have similar instrumentation such that most measurements names are the same (i.e. ENGINE-TEMPERATURE, etc) and support this out of a single control room with a single setup file. TC-2a Combined Mission Outline
Details
  • Define a test mission for hypothetical fighter jet #1 and a minimal on-board network for same
  • Define a test mission for hypothetical fighter jet #2 and a minimal on-board network for same
TC-2b Combined Mission Detail
Details
  • In development
 Multiple instrumentation networks sharing a measurement Pending
top

6.2 Signal Characteristics User Stories

User Story Test Case Instance Document Line Nos.
US-3 As a test engineer, I want to be able to describe the signal characteristics necessary to decipher digitally encoded data being carried by the signal so that I can monitor in-flight progress and process and assess the test results. Pending Pending Pending
top

6.3 Metadata User Stories

User Story Test Case Deficiencies Instance Document Line Nos.
US-4 As a test engineer, I want to be able to define the data that describes the general information for my test including program name, test article, MDL version, origination date, POC information, multiple data sources and security classification so that I know why the test is needed. TC-4 Mission Metadata
Details
  • Define a test mission for hypothetical fighter jet #1 and a minimal on-board network for same
  • Security classification: UNCLASS
  • POC: Wile E. Coyote of ACME Corp located at 123 Roadrunner Way, (555)555-5555
  • Origination date: April 1, 2016
  • PCM and bus data sources
  • There is no explicit POC element in the MDL schema. This information was captured as generic parameters.
  • There is no explicit security classification element in the MDL schema. This information was captured as generic parameters.
  • There is no explicit origination date element in the MDL schema. This information was captured as generic parameters.
  • Program name and test article were included in the description element
 Test Mission Metadata All
top

6.4 RF Data Link User Stories

User Story Test Case Instance Document Line Nos.
US-x Pending. Pending Pending Pending
top

6.5 Multiplex Waveform User Stories

User Story Test Case Instance Document Line Nos.
US-x Pending. Pending Pending Pending
top

6.6 PCM Format User Stories

User Story Test Case Instance Document Line Nos.
US-11 As a test engineer, I want to be able to define the data that describes the PCM format including data link name, PCM format code, bit rate, encryption, polarity, auto-polarity correction, data direction, data randomization, randomizer length, type format, common word length, word transfer order, parity, number of minor frames, number of words in a minor frame, sync type, synchronization pattern length, synchronization pattern, in sync criteria, sync pattern criteria, out of sync pattern criteria, number of subframe ID counters, subframe ID counter name, subframe sync type, subframe ID counter location, ID counter msb starting bit location, ID counter length, ID counter transfer order, ID counter initial value, initial count subframe number, ID counter end value, end count subframe number, count direction, so that I know what the PCM format looks like. TC-7 PCM Format Metadata Description
Details:
  • Name: PCM_STREAM
  • Input data PCM code: NRZ-L
  • Input data bit rate: 2000000
  • Input data encrypted: Unencrypted
  • Input data polarity: Normal
  • Input data auto polarity correction: Yes
  • Input data data direction: Normal
  • Input data data randomized: No
  • Input data randomized length: Not Applicable
  • Format type format: Class 1
  • Format common word length: 16
  • Format word transfer order: MSB First
  • Format Parity: None
  • Format minor frame number of minor frames: 5
  • Format minor frame words per minor frame: 96
  • Format sync type: Fixed Pattern
  • Format sync pattern: 11111010111100110010000001110101
  • Sync criteria in sync criteria: Not Specified
  • Sync criteria in sync number of FSP bits: 0
  • Sync criteria out sync number of FSP bits: 0
  • Subframe synchronization ID counter name: SFID
  • Subframe synchronization ID counter sync type: ID Counter
  • Subframe synchronization ID counter location: 16
  • Subframe synchronization ID counter counter starting bit location: 16
  • Subframe synchronization ID counter counter length: 1
  • Subframe synchronization ID counter transfer order: Default
  • Subframe synchronization ID counter initial value: 0
  • Subframe synchronization ID counter initial minor frame number: 1
  • Subframe synchronization ID counter end value: 1
  • Subframe synchronization ID counter end minor frame number: 2
  • Subframe synchronization ID counter count direction: Increasing
 PCM Format Metadata All
US-12 As a test engineer, I want to be able to define a PCM matrix for storing measurements so that I can efficiently utilize bandwidth. Pending Pending Pending
US-13 As a test engineer, I want to be able to define the sampling rate for a given measurement, so that I can accurately and efficiently pack measurements into a PCM matrix. Pending Pending Pending
US-14 As a test engineer, I want to be able to define a minor frame synchronization pattern for my bit stream so that I can identify the start of the minor frame. Pending Pending Pending
US-15 As a test engineer, I want to be able to define a sub-frame synchronization counter for my bit stream so that I can identify the start of the test data. Pending Pending Pending
US-16 As a test engineer, I want to be able to describe the structure of a PCM major frame using a name, encoding and data rate, common word length, transfer order, parity , number of minor frames, length of the minor frame (in words and bits, respectively), minor frame sync pattern and subframe sync method so that the PCM frame can be processed correctly. Pending Pending Pending
US-17 As a test engineer, I want to be able to describe the contents (where the measurements are located) of a PCM major frame using the measurement list name, the number of measurements in the major frame, the name that identifies a specific measurement, parity type, location of parity in the measurement, measurement transfer order, how to locate the measurement within the major frame, the number of location definitions, the number of fragments (if any), word position, word interval, frame position, frame interval, bit mask (if any) so that the measurements can be extracted from the PCM stream. Pending Pending Pending
US-18 As a test engineer, I want to be able to describe the contents of a PCM major frame using the "word and frame" pattern so that I follow the best practices of the community. Pending Pending Pending
US-19 As a test engineer, I want to be able to define the PCM format for storing a measurement so that I know what the measurement is. Pending Pending Pending
US-20 As a test engineer, I want to be able to define where measurements are located in a PCM major frame using fragments, measurement locations, word position and interval, frame position and interval so that I know where the measurement is in the PCM frame. Pending Pending Pending
US-21 As a test engineer, I want to be able to define packed flag word and individual flag bits that reference it using the “relative measurements” pattern in which a measurement is packed into the same location as another measurement (by referencing that measurement name) using a bit mask so that I can follow the best practices of the community. Pending Pending Pending
US-22 As a test engineer, I want to be able to define the location of a measurement using a reference to a measurement name “placeholder” that maps to a specific word and frame, using the “relative measurements” pattern so that I can refer to measurement locations using names instead of word and frame numbers. Pending Pending Pending
US-23 As a test engineer, I want to be able to describe the contents of a PCM major frame using a minor frame measurement in which the measurement appears in exactly one word position within every minor frame so that I follow the best practices of the community. TC-11 One Measurement in Exactly One Word Position in Every Minor Frame Pending Pending
US-24 As a test engineer, I want to be able to describe the contents of a PCM major frame using a minor frame supercommutated measurement in which the measurement appears in multiple word positions evenly spaced within every minor frame so that I follow the best practices of the community. TC-12 Minor Frame Supercommutated Pattern (evenly spaced) Pending Pending
US-25 As a test engineer, I want to be able to describe the contents of a PCM major frame using a minor frame supercommutated measurement in which the measurement appears in multiple word positions unevenly spaced within every minor frame so that I follow the best practices of the community. Minor Frame Supercommutated Pattern (unevenly spaced) Pending Pending
US-26 As a test engineer, I want to be able to describe the contents of a PCM major frame using a minor frame fragmented measurement in which the measurement spans multiple word positions because its length is greater than the common word length and the fragments appear in exactly one word position within every minor frame so that I follow the best practices of the community. TC-13 Minor Frame Fragmented Pattern Pending Pending
US-27 As a test engineer, I want to be able to describe the contents of a PCM major frame using a subcommutated measurement in which the measurement appears in exactly one word position within exactly one minor frame of the major frame so that I follow the best practices of the community. TC-14 Subcommutated Measurement Pattern Pending Pending
US-28 As a test engineer, I want to be able to describe the contents of a PCM major frame using a subframe supercommutated (supersubcommutated) measurement in which the measurement appears in multiple frame positions evenly spaced within exactly one word position so that I follow the best practices of the community. TC-15 Supersubcommutated Measurement Pattern Pending Pending
US-29 As a test engineer, I want to be able to describe the contents of a PCM major frame using a fragmented subcommutated measurement in which the measurement spans multiple word positions because its length is greater than the common word length and each of its fragments appears in exactly one word position within exactly one minor frame so that I follow the best practices of the community. TC-15 Fragmented Subcommutated Measurement Pattern Pending Pending
US-30 As a test engineer, I want to be able to describe the contents of a PCM major frame using a fragmented subframe supercommutated (supersubcommutated) measurement in multiple unevenly spaced locations in which the measurement spans multiple word positions because its length is greater than the common word length (fragmented) and each of its fragments appears in multiple word position anywhere in the minor frame so that I can fit aperiodic data into a periodic PCM stream. TC-16 Fragmented Supersubcommutated Measurement Pattern Pending Pending
US-31 As a test engineer, I want to be able to describe the contents of a PCM major frame using a minor frame fragmented and supercommutated measurement in which the measurement spans multiple word positions because its length is greater than the common word length and the fragments appear in multiple word positions within every minor frame so that I can achieve a higher sample rate than the minor frame rate. TC-17 Fragmented Supercommutated Measurement Pattern Pending Pending
US-32 As a test engineer, I want to be able to use concatenation to fit measurements that are larger than the common word length into multiple word locations where not all bits in a word are used, so that I follow the best practices of the community. Concatenation Pending Pending
US-33 As a test engineer, I want to have multiple measurements in a single word location, using bitmasks, because the measurements occupy less bits than the common word length, so that I can preserve PCM space. Multiple Measurements in a Single Work Location Pending Pending
US-34 As a test engineer, I want to define two measurements in the same location with two different EU conversions (e.g. temp F, temp C), so that I can conveniently display the same measurement in different units. Two Measurements in Same Location with Different EU Conversion Pending Pending
US-35 As a test engineer, I want to capture the telemetry format (PCM) for a weapons system that defines multiple embedded PCMs. Multiple Embedded PCMs Pending Pending
US-36 As a test engineer, I want to capture an asynchronous supercommutated or subcommutated embedded format with a fixed bit rate, so that I can multiplex multiple data streams on a single transmitter. Asynchrounous Embedded Format with Fixed Bit Rate Pending Pending
US-37 I want to capture an asynchronous supercommutated or subcommutated data merge format with overhead bits so that I can merge in a sub-format with a variable bit rate. Asynchronous Data Merge Format Pending Pending
top

6.7 Measurement User Stories

User Story Test Case Instance Document Line Nos.
US-38 As a test engineer, I want to define the measurements for placing into a PCM frame so that the test measurements are recorded. TC-9 Measurement Definition Pending Pending
US-39 As a test engineer, I want to be able to define the data for a measurement including a name, parity, measurement transfer order, measurement location type, bit mask so that I know what the measurement is. TC-9 Measurement Metadata Pending Pending
US-40 As a test engineer, I want to be able define that data that describes the test measurements including the measurements for the test so that I know what data is to be collected. TC-9 Test Measurements Pending Pending
US-41 As a test engineer, I want to be able to define a measurement list so that I can organize the test measurements. TC-9 Measurement List Pending Pending
US-42 As a test engineer, I want to be able to define the data for a measurement list including a name and the measurements in the list so I know what the measurement list is. TC-9 Measurement List Metadata Pending Pending
US-43 As a test engineer, I want to be able to define the measurements in the measurement list so that I know what data is being collected. TC-9 Measurement List Content Pending Pending
US-44 As a test engineer, I want to be able to define a measurement list change, where the format does not change but the contents of the format change during transmission. Pending Pending Pending
US-45 As a test engineer, I want to be able to define a format change, where the shape, content, and bit rate of the format change during transmission. Pending Pending Pending
top

6.8 Data Conversion User Stories

User Story Test Case Instance Document Line Nos.
US-46 As a test engineer, I want to define a method for converting raw telemetry bits to engineering units so that I can analyze test data. Pending Pending Pending
US-47 As a test engineer, I want to be able to define the data that defines the conversion method including the measurement name to link to the measurement list, a description of the measurement, the binary format of the measurement, and data conversion of the measurement in the PCM stream so that I can analyze test data. Pending Pending Pending
US-48 As a test engineer, I want to be able to define a pair set conversion method (PRS) so that I can analyze test data. Pending Pending Pending
US-49 As a test engineer, I want to be able to define a coefficients conversion method (COE) including the order of the polynomial curve fit, the 0th coefficient and the nth coefficient so that I can analyze test data. Pending Pending Pending
US-50 As a test engineer, I want to be able to define a negative powers of X coefficients conversion method so that I can analyze test data. Pending Pending Pending
US-51 As a test engineer, I want to be able to define a derived conversion method (DER) so that I can analyze test data. Pending Pending Pending
US-52 As a test engineer, I want to be able to define a discrete conversion method (DIS) so that I can map discrete values to text strings. Pending Pending Pending
US-53 As a test engineer, I want to be able to define a PCM time conversion method (PTM) so that I can analyze test data. Pending Pending Pending
US-54 As a test engineer, I want to be able to define a 1553 time conversion method (BTM) so that I can analyze test data. Pending Pending Pending
US-55 As a test engineer, I want to be able to define a digital voice conversion method (VOI) so that I can analyze test data. Pending Pending Pending
US-56 As a test engineer, I want to be able to define a digital video conversion method (VID) so that I can process video embedded in a PCM stream. Pending Pending Pending
US-57 As a test engineer, I want to be able to define a special processing conversion method (SP) so that I can analyze test data. Pending Pending Pending
top

6.9 Transmission User Stories

User Story Test Case Instance Document Line Nos.
US-58 As a test engineer, I want to be able to define the data for describing the RF source so that the transmitter can accurately transmit the PCM data to the ground station antenna, receiver and recording device. TC-58 Radio definition
Details
Extend test case TC-1e with the following:
  • Define a radio with a network interface
  • Add the appropriate configuration seetings
  • Connect the radio to the switch via an ethernet connection
 Adding a radio to the test article network Pending
US-59 As a test engineer, I want to be able to define the data to setup the ground station so that it can receive the RF signal. TC-59 Ground station radio definition
Details
Extend test case TC-58 with the following:
  • Define a ground station network
  • Define a radio in the ground station network
  • Define an RF link from the test article radio to the ground station radio
 Adding a ground station network Pending
top

6.10 Recorder User Stories

User Story Test Case Instance Document Line Nos.
US-60 As an instrumentation engineer, I want to be able to extract the measurements recorded during a test. TC-60 Test article recorder definition
Details
Extend test case TC-58 with the following:
  • Add a recorder to the test article network
  • Make the recorder a "data sink" for the MDL message
  • Connect the recorder to the switch
 Adding a recorder to the test article network Pending
US-61 As an instrumentation engineer, I want to be able to set up the recorder to record the data on the ground and on-board the test article. TC-61 Ground station recorder definition
Details
Extend test case TC-59 with the following:
  • Add a recorder to the ground station network
  • Add a recorder to the ground station network
  • Make the recorder a "data sink" for the MDL message
  • Connect the recorder to the switch
 Adding a recorder to the ground station network Pending
US-62 As an instrumentation engineer, I want to be able to setup the recorder to record the following data types: PCM Input, Video Input, Analog Input, 1553 Input, Discrete Input, IRIG Time Input, UART Input, ARINC 429 Input, Message Data Input, Image Data Input, IEEE-1394 Input, Parallel Input, Ethernet Input, TSPI/CTS Input and CAN bus Input. Pending Pending Pending
US-63 As an instrumentation engineer, I want to be able to setup recorder settings. Pending Pending Pending
US-64 As an instrumentation engineer, I want to be able to enable indices. Pending Pending Pending
US-65 As an instrumentation engineer, I want to be able to setup events and triggers. Pending Pending Pending
US-66 As an instrumentation engineer, I want to be able to setup filters to filter the data recorded to the device. Pending Pending Pending
top

6.11 Data Acquisition User Stories

User Story Test Case Instance Document Line Nos.
US-67 As an instrumentation engineer, I want to be able to record the data on the ground and on-board the test article. Pending Pending Pending
top

6.12 Signal Conditioning User Stories

User Story Test Case Instance Document Line Nos.
US-68 As an instrumentation engineer, I want to configure devices to perform analog signal conditioning. TC-68 Analog signal card configuration
Details (extending TC=61):
  • For each signal conditioning card, specify an appropriate amplification (attenuation), filtering and excitation on the signal conditioning card output ports
 Signal conditioning Pending
US-69 As an instrumentation engineer, I want to configure signal conditioning to (optimally) match the signal source with the data acquisition system. Pending Pending Pending
US-70 As an instrumentation engineer, I want to configure an analog signal conditioning device to perform amplification, attenuation, filtering, zero shifting and compensation. TC-68 Analog signal card configuration Signal conditioning Pending
US-71 As an instrumentation engineer, I want to configure frequency filtering so that I transmit wanted and attenuate unwanted frequent content in the measurement signal so that I can reduce the amount of noise outside the data bandwidth and can select certain frequency bands. Pending Pending Pending
US-72 As an instrumentation engineer, I want to configure a low-pass filter to pass frequencies below a cut-off value. Pending Pending Pending
US-73 As an instrumentation engineer, I want to configure a high-pass filter to pass frequencies above a cut-off value. Pending Pending Pending
US-74 As an instrumentation engineer, I want to configure a band-pass filter to pass frequencies within a given band. Pending Pending Pending
US-75 As an instrumentation engineer, I want to configure a band-reject filter to reject frequencies within a given band. Pending Pending Pending
top

6.13 Temperature Measurement User Stories

User Story Test Case Instance Document Line Nos.
US-76 As an instrumentation engineer, I want to collect and store temperatures on the test article so that I can validate performance of the test. TC-76 Instrumentation Network for Measuring Temperature
Details:
  • Define a temperature measurement
  • Define a network that consists of a DAU, signal conditioning card and thermocouple
  • Connect the thermocouple to the signal conditioning card
  • Connect the signal conditioning card to the DAU
 Instrumentation Network Pending
US-77 As an instrumentation engineer, I want to configure a telemetry system for transmitting temperature measurements so that I can send measurements to a recorder or ground station. Pending Pending Pending
US-78 As an instrumentation engineer, I want to be able to setup filters to filter the data recorded to the device. Pending Pending Pending
US-79 As an instrumentation engineer, I want to perform signal conditioning on temperature measurements. Pending Pending Pending
US-80 As an instrumentation engineer, I want to sample temperature at very low rates so that I can make the best use of transmission bandwidth (temperate changes at low rates). Pending Pending Pending
US-81 As an instrumentation engineer, I want to measure engine air intake temperature. Pending Pending Pending
US-82 As an instrumentation engineer, I want to measure temperature with a device that can operate within the expected temperature ranges (local climate and normal operating range) so that I can have access to temperature ranges at and around the test center. Pending Pending Pending
US-83 As an instrumentation engineer, I want to be able to use several different types and styles of thermocouples on the same test article so that I can have advanced knowledge of the expected range of temperatures and the environment in which the measurement is to be made. Pending Pending Pending
US-84 As an instrumentation engineer, I want to measure engine intake air temperature using a T-type thermocouple. Pending Pending Pending
top

6.14 Bus Monitor User Stories

User Story Test Case Instance Document Line Nos.
US-85 As an Instrumentation Engineer, I want to monitor data buses for test item information so that I can record and stream test item data. Pending Pending Pending
US-86 As an instrumentation engineer, I want to be able to setup an ARINC-429 bus monitor to parse / filter specific messages by label and SSM values and specify the measurements to be read from these filtered messages so that my test requirements are met. Pending Pending Pending
US-87 As an instrumentation engineer, I want to be able to setup a MIL-STD-1553 bus monitor to parse / filter specific messages and specify the measurements to be read from these filtered messages so that my test requirements are met. Pending Pending Pending
US-88 As an instrumentation engineer, I want to be able to setup a PCM Stream monitor to parse / filter specific messages and specify the measurements to be read from these filtered messages so that my test requirements are met. Pending Pending Pending
top

6.15 Data Stream Encoder User Stories

User Story Test Case Instance Document Line Nos.
US-89 As an instrumentation engineer, I want to be able to store a measurement collected during a test to a data stream using a data encoder so that my test requirements are met. Pending Pending Pending
US-90 As an instrumentation engineer, I want to be able to store a measurement collected during a test to a PCM frame via a PCM encoder so that my test requirements are met. Pending Pending Pending
US-91 As an instrumentation engineer, I want to be able to store a measurement collected during a test to an iNet TmNS message via an iNet network data encoder so that my test requirements are met. Pending Pending Pending
US-92 As an instrumentation engineer, I want to be able to store a measurement collected during a test to generic network message via a network data encoder so that my test requirements are met. Pending Pending Pending
top