Streaming Flight Test Data in Defense Applications | A Growing Need

October 9, 2024

For analog data (think acceleration, temperature, pressure, strain, angular rate), many times capturing what a test article experiences can be done onboard. Later, the data acquisition system can be hooked up to a computer for download and analysis.

But for this type of data in an aerospace/defense test scenario, many times this isn’t good enough. Real time decisions may be made based on what that aircraft is performing or experiencing. It could be the test article is never going to return, and thus there’s no way to retrieve that data post-test. Perhaps a large group of observers, from the on-the-ground engineers all the way up to top brass, all want to watch the test unfold together. A live feed is increasingly called for in these scenarios.

Maybe it’s a rocket headed out over the pacific. Or several unmanned combat aircraft performing high-g maneuvers as they escort their human-piloted F35’s (think CCA – Collaborative Combat Aircraft). Every piece of data could be critical, and it’s all happening very quickly. A live feed is, again, appealing.

But several challenges immediately arise:

How is this data standardized so that multiple test range elements can use and understand it?

How is the data secured and protected from adversaries?

Where are the bottlenecks for all this data heading down to the ground?

Data Standardization

Thankfully, to make sure data can be used in a standardized way, the Range Commanders Council has the IRG-106 publication. This sub-group has many responsibilities but dictating how digital data recorders can send out their data is on the list. If you’re looking to standardize in this area, take a look at Chapter 10. People way smarter than me have broken down guidelines for analog data so that everyone is playing by the same rules. There are some complexities of course, but many bases around the U.S. already adhere to this program.

If you're brand new to IRIG-106, check out the Wiki dedicated to it. This site is incredibly helpful for learning the rules/searching terms you may not recognize etc.

This IRIG-106 standard may not match what you need or where you operate, but it's one to consider if you're just starting out, particularly here in the U.S.

Data Security / Operational Security

One huge benefit of data only going to onboard memory is that’s the only place where it’s held. Therefore, an adversary would have to retrieve that memory locally. But once it goes over the air, that all changes. So how do you limit the exposure?

A few methods to consider:

Conversions: To convert any analog’s sensor from millivolts to some understandable unit (aka Engineering Unit like Gs' in acceleration) means you need several variables defined. Instead, simply sending out the “raw” millivolts means your adversary no longer has that translation information. You were measuring strain? Possibly, but with no titles or conversion variables, it’s just raw data

TMATS: If you follow Chapter 10 (see previous section), the TMATS is what is streamed out to tell the receiving parties what data is inbound (not the data itself). Sending out that TMATS less frequently (or not at all) can deny the enemy this piece of conversion information

Encryption: Good news. Encryption of data, even from an ethernet source, is possible in the field, even in a defense scenario. I do not want to endorse any one solution but check out Silvus Radios and any technology that can do what they do. Again, not an endorsement, but a candidate I know of out there that could at least be a starting point for your research for off the shelf products, if not the end solution.

Data Bottlenecks

If you are telemetering this data down from the air/space to a ground station, it may be stuck in a pipe with all the other data heading downstream. What’s more, your available bandwidth may be well below what sensors nowadays can output. How do you deal with this?

A few solutions:

Lower sample rates as much as is reasonable. Don’t break any best practices here. You want a high enough sample rate/signal processing/filtering etc. For good data. But if you can, lower the rates within reason.

Oversample to onboard memory: Let’s say what you can digest down on the ground is pretty limited. Try to sample with best practices for data being stored onboard (to review later if this is possible), but send out a much more limited data stream for real-time operational decisions during the test itself

Pick and choose: Maybe one sensor really should sample only once per second (like temperature), but others could be 10,000 samples a second (maybe strain). See if you can divide them up and match their sample rates to get the most out of your data acquisition hardware and telemetry makeup.

Final Notes

As with all such advice, bench test first.

Make sure you prepare well before test day.

Reach out to industry professionals for help. There’s a good chance they love talking about this sort of thing. See what they think.

If you’re purchasing any equipment from any manufacturer, be sure to ask them the hard deep technical questions. You want confidence that the tools meet your needs and that their support team will understand what’s critical to your mission.

What Do You Think

What have I missed? What else matters in the field?

Have you run into this sort of need recently?

What’s your experience been with telemetering data?

How might AI affect this data need?

Disclaimer

All statements and views are solely the author’s and don’t reflect the opinions or beliefs of my own company or parent affiliation (present or past).