Standards Conformance & Data Integration for T&E

A schema checks that a document has the right shape. It cannot check that the configuration is correct. A telemetry standard’s real rules — the dependencies between fields, across documents, and across vendors — cannot be written in an XML schema, so today they live in prose and in the hard-coded procedures of each vendor’s software. VIStology makes those rules executable and standards-based, decoupled from any vendor’s code, so a machine can enforce the whole standard — and revising the standard does not mean rewriting the validator. A standard change is a data change, not a software change.

The Challenge: A Schema Cannot Check a Configuration

Test & Evaluation telemetry runs on a real, named, government-maintained standard. IRIG 106 is, in the ITC’15 paper’s words, “a comprehensive telemetry standard maintained and developed by the Telemetry Group of the Range Commanders Council (RCC)”, and it carries three XML-based components — the Telemetry Attributes Standard (TMATS), the Data Display Markup Language (DDML) and the Instrumentation Hardware Abstraction Layer (IHAL). Separately, iNET’s Metadata Description Language (MDL) is, in the same paper’s careful phrasing, only “anticipated to be incorporated into IRIG” — not yet part of it. This is flight-test infrastructure, not a toy.

The trouble is what a schema can and cannot say. An XML Schema pins down structure — which elements may appear, their data types, the cardinality of a single element. It cannot express the rules that actually make a configuration correct: the dependencies between fields, between documents, and between vendors. The ITC’15 paper states the gap exactly:

“the schemas cannot express all dependencies between XML elements and attributes, both within a single document and across multiple documents. This prohibits the XML validation process from being fully automated with standard schema processors.”

So the meaning has to live somewhere, and today it lives in code — each vendor’s code: “Since XML does not capture the semantics of particular domains, the applications that handle the XML documents must hard-code procedures for the interpretation of the meaning of XML documents.” That is the whole problem in one sentence. The rules a standard actually imposes are compiled into each vendor’s validator, so every change to the standard is a change to software — and no two vendors’ validators need agree on what the standard means.

Our Approach: Lift the Data, Then Check Meaning

The method has two moving parts, and both are data, not code: lift the vendor’s XML into an RDF/OWL graph with a generic, schema-agnostic lifter, then evaluate the standard’s real rules — the cross-field, cross-document, cross-vendor dependencies no schema can express — as declarative constraints over that graph. One architecture has carried two engines: BVR rules on BaseVISor in Phase I, and TACL, a proposed extension of W3C’s SHACL standard, on xVISor in Phase II. The two engines are kept straight on the use-case pages, along with what was demonstrated (feasibility) and what was never measured (everything else).

A schema checks shape; the standard's real rules live above it, in meaning. Two horizontal planes. In the lower plane, syntax: an MDL/XML configuration document is checked by an XML Schema validator, which confirms the document is well-formed and schema-valid — correct element structure, data types, and single-element cardinality. But a schema cannot express dependencies between fields, dependencies across documents, or system-wide limits such as bandwidth, weight and power budgets, so the configuration can pass the schema and still be wrong. An upward arrow labeled semantic lifting shows the same XML being converted automatically into an RDF/OWL graph with formal semantics. In the upper plane, meaning: declarative constraints are evaluated over the lifted graph, decoupled from any vendor's source code. The same architecture has been realized with two engines across two eras — Phase I (ITC 2015) expressed rules in BVR executed by the BaseVISor reasoner; Phase II expressed constraints in TACL, a W3C SHACL extension, executed by VIStology's xVISor engine over SHACL, SHACL-SPARQL and OWL. The output is the class of violations a schema processor cannot find. The approach was demonstrated feasible, not benchmarked; the prototype is named xVISor. A Schema Checks Shape. The Rules Live Above It. THE SYNTAX PLANE — WHAT A SCHEMA CAN SEE MDL / TMATS document <NetworkNode Name="DAU1"> <Measurement ID="m17"> <SampleRate>96</…> </Measurement> </NetworkNode> telemetry configuration, in XML XML Schema validator • element structure • data types • one element’s cardinality ✓ well-formed & schema-valid What a schema cannot express • dependencies between fields — this rate implies that mode • dependencies across documents & vendors • system-wide limits — bandwidth, weight, power • scoped uniqueness — an RF MAC may not repeat these live in each vendor’s hard-coded software The document is schema-valid — and the configuration can still be wrong. “the applications that handle the XML documents must hard-code procedures for the interpretation of the meaning” — ITC 2015 semantic lifting XML → RDF / OWL — automatic and schema-agnostic; the meaning becomes formal, and computable. THE MEANING PLANE — WHERE THE STANDARD’S REAL RULES RUN the lifted graph (RDF / OWL) the same data, now with formal semantics — grounded on VIStology’s NuVio + domain ontologies for MDL / TMATS. constraints reason over meaning, not tree position one architecture, two engines — the rules are data, kept out of the validator’s code PHASE I · ITC 2015 BVR on BaseVISor rules in the BaseVISor rule language, executed by the BaseVISor reasoner PHASE II · TACL SHACL + OWL on xVISor TACL, a W3C SHACL extension, run by xVISor — not BaseVISor; an open standard Output: the violations a schema processor cannot find “DAU1 sample rate 96 is not a power of 2”  ·  “RF MAC repeats across two RANs”  ·  “power budget exceeded across vendors” — and change the standard by editing the rules, not by rewriting the validator. a standard change is a data change, not a software change The approach was demonstrated feasible, never benchmarked: the prototype (xVISor) was “successfully tested with MDL and TMATS data”; DDML and IHAL are named as context, not validated, and MDL is not yet part of IRIG 106. Moskal, Kokar & Morgan, “Semantic Validation of T&E XML Data,” International Telemetering Conference 2015. DISTRIBUTION A, 412 TW-PA-15337.
Figure 1. A schema checks shape; the rules live above it. An XML Schema can confirm a telemetry configuration is well-formed and schema-valid, yet say nothing about the cross-field, cross-document and system-wide constraints that decide whether the configuration is actually correct — those live, today, in each vendor’s hard-coded software. VIStology lifts the same XML into an RDF/OWL graph and evaluates the constraints there, decoupled from code. One architecture has carried two engines: BVR on BaseVISor in Phase I (ITC’15), and TACL — a W3C SHACL extension — on xVISor in Phase II. The approach is demonstrated feasible, not benchmarked.

The same method, hardened into a shipping product

This is a research lineage, and we label it as one on the use-case pages. But the method — semantic conformance checking with a standard’s constraints held as data, decoupled from the tool’s source code — is not only a proposal. VIStology matured the same method in a different standards domain into SCA-Pass, a shipping product that checks SCA 4.1 radio-waveform applications for conformance. The two are siblings, not the same product: SCA-Pass targets radio waveforms while this work targets telemetry (IRIG 106 / MDL); SCA-Pass is a released, shipping product while xVISor is an SBIR research prototype; and even their engines differ. What travels between them is the discipline, not the credentials — and we are careful never to lend one’s maturity to the other.

Use Cases

Standards Conformance Testing

The standard’s rules, executable and vendor-independent: XML lifted to OWL and checked by declarative constraints — TACL, a proposed SHACL extension a person can read.

Learn more →

Data Integration

Two independently built tools interoperating through the standard itself: xVISor inside SwRI’s iNET System Manager, a constraint violation surfaced live in the GUI.

Learn more →

Proof Points

No paper in this arc carries a number. What they carry is provenance, an open W3C substrate, a working engine and one demonstrated integration — and each is labeled for exactly what it is, because every claim here is checkable against an open PDF or a federal spending record.

U.S. Air Force SBIR

Two Air Force Contracts, “RuBX”

The work was built under two US Air Force SBIR contracts on topic AF141-227, “Rule-Based XML Validation for T&E (RuBX)”, sponsored through the Air Force Test Center / 412th Test Wing at Edwards AFB: Phase I, FA9302-14-M-0002 ($149,997, 2014–2015) and Phase II, FA9302-16-C-0017 ($744,916, 2016–2018, with a no-cost extension). Both FA-numbers are named verbatim in the ITC papers’ acknowledgments and independently confirmed on USASpending; public-release markings 412 TW-PA-15337, 412TW-PA-18343 and 412TW-PA-19431. Boundary: these were SBIR research contracts — the second ended in December 2018. No program of record, no fielding.

In the room

A Recurring Slot in the RCC Telemetry Group

Across 2014–2019 VIStology took part in nine meetings of the Range Commanders Council Telemetry Group — the body that maintains the IRIG 106 telemetry standards — with a named, recurring SBIR presentation slot in its data-multiplex committee, alongside industry (Boeing) and another SBIR performer (KBSI). Real exposure to the government range community, NAVAIR and the iNET program. Boundaries: VIStology was an invited presenter and participant, not a member (the members are the U.S. government ranges) and not an author of IRIG 106, TMATS, DDML, IHAL or MDL. The committee is government-chaired; KBSI was a competing SBIR, so VIStology did not solely drive the validation effort.

Same method, shipping

The Productized Sibling: SCA-Pass

The method behind this research — a standard’s un-schematizable constraints captured as data, decoupled from the tool’s code — is the same one VIStology matured into SCA-Pass, a shipping conformance product for SCA 4.1 radio-waveform applications. It shows the approach is not only a proposal. Boundaries, kept strictly: SCA-Pass and xVISor are the same method in different domains, not the same product — different standards (SCA vs. IRIG 106 / MDL), different maturity (a released product vs. an SBIR prototype), and different engines. SCA-Pass’s product credentials belong to SCA-Pass; this work’s Air Force SBIR provenance belongs to this work.

Selected Publications

The record behind VIStology’s T&E standards-conformance practice — three peer-reviewed ITC papers and one workshop presentation. Read them; the limits on this page are the limits in these sources.

Semantic Validation of T&E XML Data

Moskal, J.J., Kokar, M.M. & Morgan, J.

Proceedings of the International Telemetering Conference (ITC 2015), International Foundation for Telemetering

View Publication

Introducing TACL – A Proposal for a New Standard T&E Constraint Language

Moskal, J.J., Whittington, A., Kokar, M.M. & Abbott, B.

Proceedings of the International Telemetering Conference (ITC 2018), International Foundation for Telemetering

View Publication

Validation Protocol – The Missing Puzzle Piece

Moskal, J.J., Whittington, A., Morgan, J., Kokar, M.M. & Abbott, B.

Proceedings of the International Telemetering Conference (ITC 2019), Vol. 55, International Foundation for Telemetering

View Publication

Building Multi-Vendor T&E Systems in iNET

Moskal, J.J., Kokar, M.M., Abbott, B., Whittington, A. & Morgan, J.

23rd Test & Training Instrumentation Workshop (T&TIW / ITEA), 2019 — presentation

View Slides

Provenance, stated once. This work was performed under two US Air Force SBIR contracts, “Rule-Based XML Validation for T&E (RuBX)” — FA9302-14-M-0002 (Phase I, $149,997) and FA9302-16-C-0017 (Phase II, $744,916) — sponsored through the Air Force Test Center / 412th Test Wing at Edwards AFB, with Southwest Research Institute as VIStology’s subcontractor; the FA-numbers appear in the ITC papers’ acknowledgments and on USASpending, and the papers were cleared for public release (412 TW-PA-15337, 412TW-PA-18343, 412TW-PA-19431). The fourth entry is a workshop presentation deck, not a peer-reviewed paper, and cites only the SBIR topic AF141-227 — the FA-numbers are sourced to the papers, not to the deck. None of the four reports a performance evaluation.

See the full list of VIStology publications →

Related

SCA-PassThe same conformance method, productized — automated conformance testing for SCA 4.1 radio waveforms. Semantic IntegrationLifting somebody else’s schema — XML, XSD, relational — into a model a reasoner can use. Our OntologiesThe foundational and domain models the lifted data and the constraints are written against. BaseVISorThe OWL 2 RL reasoner behind the Phase I / ITC’15 rule validation. Dynamic Spectrum SharingThe same policy-as-data thesis, in a radio: a rule change is a data change, not a software change. PublicationsOur full body of peer-reviewed research.

Take the Rules Out of the Validator

If your standard’s real constraints are compiled into a vendor’s configuration software — where every change to the standard is a change to code, and no two vendors’ validators agree — we can help you make those rules executable, standards-based, and independent of any one tool. A standard change should be a data change, not a software change.

Get in Touch