# 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. RANConfigs [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 DataOperations
      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
      9. Simultaneous Sampling [Recommended]
   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. Multiple Apps per NetworkNode
   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. Derived Processing
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:

- MDL File: Link to the example MDL file. The example MDL files are schema-valid, and they have been updated to the most recent version of the MDL schema.
- Date Introduced: Date the example was first released.
- Created with Schema: Version of the MDL schema that the example was initially created with.
- References: Reference material that may provide additional context or detail for the example. This is currently limited to Standards references and MDSWG change proposals; however, additional references, such as the ARINC 429 standard, could be added.
- Related Examples: Links to examples included in this appendix that build off of the current example.
- Description: Summary of the example. This information was taken from the material used to generate the example. For some examples, a great deal of source material was available, while for others the source material was sparse. The descriptions may also include notes and search terms to point out key elements and concepts in the MDL file.

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:

- Define the PCM frame structure using TMATS imports
- Define the four measurements and arrange them into the frame (this extends the test case that defines the entire instrumentation network)
- Package the PCM into an MDL message

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:

- Define measurements such that multiple networks can share the measurement names
- Add a temperature measurement and two pressure measurements and the supporting sensors and signal conditioning cards, which is further evolved to the following
  - Package the measurements into an MDL message
  - Add networking to the components
  - Add a radio to the test article network
  - Add a recorder to the test article network
  - Add a ground station network and radio
  - Add a recorder to the ground station network
  - Add details to the signal conditioning cards to condition the measurements
  - Add measurement requirements

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
Date Introduced | April 2016
Created with Schema | v0.8.19
References | User Stories US-4 Test Cases TC-4
Related Examples |
Description | The figure below 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
Date Introduced | April 2016
Created with Schema | v0.8.19
References | User Stories US-76 Test Cases TC-76
Related Examples |
Description | The figure below 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 TmNSManageableApp 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. The extensions for this example are shown in bold.

top

#### 2.2.2 Multiple instrumentation networks sharing a measurement

MDL File | TC-2a.xml
Date Introduced | April 2016
Created with Schema | v0.8.19
References | User Stories US-2 Test Cases TC-2a
Related Examples |
Description | The figure below 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. The extensions for this example are shown in bold.

top

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

MDL File | TC-1a.xml
Date Introduced | April 2016
Created with Schema | v0.8.19
References | User Stories US-1 Test Cases TC-1a
Related Examples |
Description | The figure below 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
Date Introduced | April 2016
Created with Schema | v0.8.19
References | User Stories US-11 Test Cases TC-7
Related Examples |
Description | The figure below 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. The extensions for this example are shown in bold.

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
Date Introduced | April 2016
Created with Schema | v0.8.19
References | User Stories US-1 Test Cases TC-1b
Related Examples |
Description | The figure below extends the instrumentation network example and defining a PCM frame example to store the measurements in the PCM frame. The extensions for this example are shown in bold.

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
Date Introduced | April 2016
Created with Schema | v0.8.19
References | User Stories US-1 Test Cases TC-1c
Related Examples |
Description | The figure below 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. The extensions for this example are shown in bold.

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
Date Introduced | April 2016
Created with Schema | v0.8.19
References | User Stories US-1 Test Cases TC-1d
Related Examples |
Description | The figure below 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. The extensions for this example are shown in bold.

top

#### 2.4.2 Adding network interfaces

MDL File | TC-1e.xml
Date Introduced | April 2016
Created with Schema | v0.8.19
References | User Stories US-1 Test Cases TC-1e
Related Examples |
Description | The figure below 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
Date Introduced | April 2016
Created with Schema | v0.8.19
References | User Stories US-58 Test Cases TC-58
Related Examples |
Description | The figure below 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. The extensions for this example are shown in bold.

top

#### 2.4.4 Adding a recorder to the test article network

MDL File | TC-60.xml
Date Introduced | April 2016
Created with Schema | v0.8.19
References | User Stories US-60 Test Cases TC-60
Related Examples |
Description | The figure below 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. The extensions for this example are shown in bold.

top

#### 2.4.5 Adding a ground station network

MDL File | TC-59.xml
Date Introduced | April 2016
Created with Schema | v0.8.19
References | User Stories US-59 Test Cases TC-59
Related Examples |
Description | The figure below 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. The extensions for this example are shown in bold.

top

#### 2.4.6 Adding a recorder to the ground station network

MDL File | TC-61.xml
Date Introduced | April 2016
Created with Schema | v0.8.19
References | User Stories US-61 Test Cases TC-61
Related Examples |
Description | The figure below 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. The extensions for this example are shown in bold.

top

#### 2.4.7 Signal conditioning

MDL File | TC-68.xml
Date Introduced | April 2016
Created with Schema | v0.8.19
References | User Stories US-68 US-70 Test Cases TC-68
Related Examples |
Description | This figure below 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. The extensions for this example are shown in bold.

top

#### 2.4.8 Measurement requirements

MDL File | TC-1f.xml
Date Introduced | April 2016
Created with Schema | v0.8.19
References | User Stories US-1 Test Cases TC-1f
Related Examples |
Description | The figure below illustrates the basic information for measurement requirements (data length, sample rate, etc.). The extensions for this example are shown in bold.

top

## 3. Test Missions

### 3.1 TestMission Framework

MDL File | TestMissionFramework.xml
Date Introduced | November 2010
Created with Schema | 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 Packages Messages DataStreams (Busses) DataOperations (transformations of data at various stages) 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
Date Introduced | December 2015
Created with Schema | 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, RANConfigs, 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 TmNSManageableApps and radio groups for the wireless source and destination link addresses respectively. The AssetAssociations section links the TmNSManageableApps 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 TmNSManageableApp section and an InternalStructure section. It is within the TmNSManageableApp 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 RANConfigs 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
Date Introduced | December 2015
Created with Schema | 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, Package descriptions, MessageDefinitions, DataStreams, and DataOperations 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, DataOperations 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 TmNSManageableApp section and an InternalStructure section. It is within the TmNSManageableApp 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
Date Introduced | November 2010
Created with Schema | 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
Date Introduced | May 2011
Created with Schema | 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 RANConfigs [Recommended]

MDL File | RANConfigs.xml
Date Introduced | February 2016
Created with Schema | 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 RANConfig that contains two Radio Groups. The RANConfig 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
Date Introduced | February 2016
Created with Schema | 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 TmNSManageableApp element and an InternalStructure element. It is within the TmNSManageableApp 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 RANConfig 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 TmNSManageableApps 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 RANConfigs and DSCPTable.

top

### 4.3 Scheduling without Link Manager

MDL File | StandaloneScheduling.xml
Date Introduced | February 2016
Created with Schema | 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 TmNSManageableApp element and an InternalStructure element. It is within the TmNSManageableApp 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
Date Introduced | February 2016
Created with Schema | 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
Date Introduced | October 2011
Created with Schema | 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
Date Introduced | February 2016
Created with Schema | 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 TmNSManageableApp 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
Date Introduced | October 2011
Created with Schema | 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 are shown as red lines and SST logical associations are shown as green lines in the figure below. Also shown are logical radio 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
Date Introduced | February 2016
Created with Schema | 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 DataOperations

MDL File | MeasurementsAndDataOperations.xml
Date Introduced | November 2010
Created with Schema | 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 operation (<DataOperation ID="GearVibCountsToGsConversion">) that represents the conversion from Counts to Volts.

top

#### 5.1.3 Bandpass Measurement

MDL File | BandpassMeasurement.xml
Date Introduced | February 2013
Created with Schema | 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
Date Introduced | February 2016
Created with Schema | 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
Date Introduced | February 2016
Created with Schema | 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
Date Introduced | May 2014
Created with Schema | 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
Date Introduced | May 2011
Created with Schema | 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
Date Introduced | November 2013
Created with Schema | 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 10 example data stream is defined in the <DataStream ID="ds-001"> element.

top

#### 5.1.9 Simultaneous Sampling [Recommended]

MDL File | Pending
Date Introduced | June 2016 (planned)
Created with Schema | v0.9.0 (planned)
References |
Related Examples |
Description | Pending

top

### 5.2 Network Nodes and Devices

#### 5.2.1 DAU

MDL File | DAU.xml
Date Introduced | June 2016
Created with Schema | 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).

top

#### 5.2.2 Recorder

MDL File | Recorder.xml
Date Introduced | June 2016
Created with Schema | 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
Date Introduced | June 2016
Created with Schema | 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
Date Introduced | June 2016
Created with Schema | 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
Date Introduced | November 2014
Created with Schema | 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 Multiple Apps per Network Node

MDL File | MultipleAppsPerNetworkNode.xml
Date Introduced | May 2011
Created with Schema | v0.8.5
References |
Related Examples |
Description | This example shows the one-to-many relationship between a NetworkNode and TmNSManageableApps (TMAs). NetworkNodes are physical devices and contain a list of TmNSManageableApps that run on the NetworkNode. The RoleID uniquely identifies a TmNSManageableApp (not the NetworkNode). The TmNSManageableApp contains the RoleID, TmNS specializations, and the SNMPInterface description. Configuring a NetworkNode (possible workflow) TmNSManageableApp(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.3 Packages and Messages

#### 5.3.1 Packaging Analog Measurements [Recommended]

MDL File | PackagingAnalogMeasurements.xml
Date Introduced | February 2016
Created with Schema | 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
Date Introduced | May 2011
Created with Schema | 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 DataOperations 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
Date Introduced | November 2013
Created with Schema | 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
Date Introduced | November 2013
Created with Schema | 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
Date Introduced | May 2011
Created with Schema | 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
Date Introduced | November 2013
Created with Schema | 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
Date Introduced | November 2013
Created with Schema | 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
Date Introduced | November 2014
Created with Schema | 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
Date Introduced | May 2011
Created with Schema | v0.8.3
References | Change Proposal MDSWG-CP-040-Rationale-for-Package-Structure-and-Mapping
Related Examples |
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
Date Introduced | February 2016
Created with Schema | 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.4 Derived Processing

MDL File | Pending
Date Introduced | June 2016 (planned)
Created with Schema | v0.9.0 (planned)
References |
Related Examples |
Description | Pending

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:

- User Stories: A user story describes a specific requirement of the schema in the terms of a user's need. An example of a user's need is "I need to configure an analog signal conditioning card"
- Test Cases: For each user story, we capture one or more test cases. A test case is a description of a very specific example of the need described in the user story. An example of a test case is "Configure the analog signal conditioning card with model number ABC123 with the specific settings X, Y, and Z."
- Instance Documents: For each user story, we then create preferably one XML instance document. The instance document is a schema-valid XML file that completely describes the information in the test case in a manner which satisfies the user story. If it is not possible to create an instance document for a given test case, then the schema is not valid and requires modification.

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:

- As a/an <user>, I want to be able to <task description>, so that <objective to meet>.

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