Military Embedded Systems

Test and measurement sector grapples with standardization, complex systems

Story

August 30, 2018

Mariana Iriarte

Technology Editor

Military Embedded Systems

The Department of Defense (DoD) no longer wants one-off systems, but rather adaptable test systems to tackle current and emerging threats that can also be used across different platforms. End game: A software-defined solution that is easily upgradable, low-cost, and open source.

The test and measurement (T&M) sector is tackling these demands and at the same time dealing with testing more complex systems in the same timescales as their predecessors under the same budget. Software reuse will be the key to meeting these requirements.

“Key trends we are seeing from our military customers include portability, ease of use, commonality, and longevity,” says Gary Tilley, senior director, sales and business development for Astronics Systems (Santa Rosa, California). “Through customer interaction and collaboration, we have found the latter two to carry the most significance.”

Nicholas Butler, global marketing lead, Aerospace & Defense at National Instruments (Austin, Texas) agrees, pointing out that DoD officials are looking for “Quality, accuracy, reliability, and longevity. However, these test customers within defense and military organizations are more and more being asked to test increasingly complex assets.”

The crux of the issue is not that test and measurement companies are being asked to test more complex systems, Butler asserts; DoD officials are also compounding the problem as these companies are “being asked to do it on the same schedules and the same budgets that they’ve always had before,” he adds. “The complexity of the asset is increasing often exponentially, but the budgets and the time frames are not increasing along with that”

In addition, defense users are “looking less and less at boxed instruments and more and more at open test environments,” says Patrick Turley, president and CEO, Ball Systems Technologies (Westfield, Indiana). PXI [an open specification for testing based on the CompactPCI bus] systems are becoming a much more prominent player than they have in the past. Also, more open software environments and less customization is at the fore of what military users are asking for.”

A key DoD document that has influenced the industry is the DoD’s Automatic Test Systems (ATS) Master Plan 2017. As stated in the document, “the DoD has four primary objectives for its future ATE systems: Reduce the total cost of ownership of DoD ATS, realize interoperable ATS, reduce logistics footprint, and improve the quality of test while reducing the repair cycle time,” says Joan Gibson, solutions business manager, A&D supply chain, at Keysight Technologies (Santa Rosa, California). “The key to attaining their goal of reducing the total cost of ownership of ATS for DoD is to stop the proliferation of unique test systems and instead standardize on designated ATS families.

“They are considering the cost and benefits over the complete system life cycle, not just the initial hardware and software cost,” Gibson continues. “The flexibility required by warfighters in modern conflict scenarios requires that the services move toward the capability of interoperability among automatic test systems. However, the closed architectures of most legacy DoD ATS prohibit interoperability. The need to rapidly deploy support, along with weapons systems, requires that all logistics footprints be reduced.”

To tackle the increase of complex systems on the battlefield and reduce system footprints, DoD users want more commonality among test systems, specifically “commonality among products, software, and processes between depot and field: [Users] want to leverage a superset/subset of test program sets (TPSs) to be able to correlate data between depot and field, maintaining a closed-loop ecosystem,” Tilley says. “The depot needs the capability to take a deep dive into the product diagnostics while the field level must be powerful, but efficient, without unnecessary testing that may waste precious time.”

When it comes to the life cycle of a product, users also need to be modern and flexible, Tilley adds. “Currently, military customers are trying to mitigate this conflict as best as they can. They need many legacy products to continue to function properly, but advances in technology require additional capability. [Military industry] customers must be able to leverage their current investment in TPSs, but need to validate those on PXI instruments before making the jump from VXI [an older spec used in test situations needing high channel density or high-speed data acquisition]. Once all TPSs have been validated on the PXI instruments, a full transition can be made to a new card cage.”

Ultimately, DoD users want it all: “They want a test platform that can adapt to these changing and evolving needs, these changing and evolving threats that sometimes can literally change on a week-to-week basis,” Butler says. “I think that’s one of the key and fairly recent trends or challenges that we are seeing from these customers.”

With the kind of adaptability that the military needs, “Software takes the center stage,” Butler adds. “Users need a software-defined platform where they can change functionality, adapt to new requirements, and meet evolving threats over time with the same hardware.”

Keysight Technologies is “using a flexible combination of commercial off-the-shelf (COTS) PXI hardware together with customizable automation software with measurement science that provides coverage for a broad range of military test programs simplifies testing needs by reducing proliferation of unique test systems which are difficult to manage and expensive to support,” Gibson says (Figure 1). “The interoperable system provides flexibility of ATE function across programs and provides the opportunity to add new capabilities in technology – while continuing to support legacy programs and requirements.”

 

Figure 1: The M9383A PXI vector signal generator. Photo courtesy of Keysight Technologies.


21

 

Budget questions: reuse or standardize?

To meet all DoD requirements, Congress recently ratified the defense budget bill, opening pockets that were tightly controlled just two years ago. With the budget approved, funding has rolled down to the T&M sector where industry representatives now have to balance between reuse on the one hand and migrating users to new, standardized, open-source platforms on the other hand.

More specifically, the “DoD/MoD [Ministry of Defense] budgets are increasing worldwide driven by increased risk related to information warfare, asymmetric threat (e.g., terrorism), and the risk of simultaneous conflict in multiple geographies and domains,” Gibson points out. “We expect high and continued growth in the U.S. for the next several years. The RDT&E (Research, Development, Test and Evaluation) ­portion of these budgets will grow faster than the overall defense budget due to need for more technologically advanced forces.”

Some of the sectors mainly affected by the budget are “those orders for products with long lead times,” Tilley says. “Big dollars are being allocated to more F-35 and weapons programs, but for programs that have traditionally trickled in over time, we are now seeing a shift to placing the full order up front, further in advance.”

The market is dealing with new systems and ensuring legacy systems are up to date. For Ball Systems, the company has experienced less of a demand with legacy systems. “In terms of market for reuse or upgrading legacy systems, we haven’t seen a lot of that, honestly,” Turley says. “Where we have seen engagements, we’ve seen customers looking for new systems, not as interested, necessarily, in adapting legacy.”

While the approved budget is still addressing some of the gaps in technology, for the warfighter to quickly see new tech on the battlefield, standardization is key. “We are seeing a pretty significant trend of these military defense customers wanting to standardize their test equipment,” Butler comments. “They want test equipment that can be used on multiple assets across multiple programs. They want test equipment that is going to be serviceable for decades.”

For that to happen, users have been taking a deeper look into systems that have been deployed for years. “They are constantly trying to figure out: How can I take all of these legacy systems and import them over to new technology that can test my legacy programs and my new programs?” Butler says.

“At the same time, there is certainly a growing market for reuse and upgrading legacy systems,” Tilley adds. “We are seeing more dollars spent on sustainment and maintenance of legacy equipment versus new system builds.”

Standardization efforts by the industry will work only by addressing all the areas, including “ensuring backwards compatibility with legacy assets,” Butler says. “It’s about getting reuse out of existing equipment. It’s about providing modular architectures that can be flexible and modified over time. It’s about being able to adapt to evolving needs and evolving threats.”

The reality of the acquisition and procurement process has changed in the past 10 years in the military defense space, Turley explains. “It’s become much more competitive, and overages are not tolerated from the government the way they used to be. So you couple that with the need to accelerate the utilization of new technologies as these threats emerge. Essentially, they need faster time-to-market solutions around test, and so there’s a desire to find tools that enable that development more quickly. And reusability of subsets of test functionality are much more desirable and are being designed into requirements.”

Security and adaptability of tools

Combating emerging threats that change as quickly as the days go by has been a core challenge over the last few years. “We’ve seen anecdotal discussion around security of information continuing to be a huge priority, both within the test systems and also as relating to testing that type of functionality in products,” Turley says. An example Turley gives is a Ball Systems-designed handheld communications bus analyzer, for use in wide instrumentation and data-collection systems. (Figure 2.)

 

Figure 2: Bus analyzer used in instrumentation and data collection. Photo courtesy of Ball Systems.


22

 

The reality is that “data has become critical for success in the battlefield – which begs the additional consideration of data security and fidelity,” Tilley asserts. “Any piece of test and measurement equipment today needs that capability – but also the ability to support older technologies that are still relevant to the warfighters.”

Astronics Test Systems has a “radio test set family with the capability to test both legacy (SINCGARS), software-defined radios (Harris 117G), and modern waveforms such as MUOS and TSM-X, with room built in for future technology,” Tilley adds (Figure 3).

 

Figure 3: ATS-300 radio test set is the depot/benchtop version of the test set family. Photo courtesy of Astronics Test Systems.


23

 

 

In this environment, tools become really important. “The tool that these customers need most is an open software platform, where they can integrate existing code with brand-new code, where they can develop proficiency in-house, in multiple types of programming languages or software, so they can continue to evolve to meet these changing or evolving threats,” Butler explains.

In addition to tools, Butler points out that there is also the service element. “I think that a lot of companies, NI included, are really starting to offer more services in addition to tools to help these customers manage and maintain equipment and to proactively manage these technology insertion cycles,” he adds.

NI’s FlexRIO (Figure 4) product line is “high-performance instrumentation modules in our PXI platform,” Butler adds. “They have large, onboard user-programmable FPGAs.”

 

Figure 4: National Instrument’s PXIe-5785 FlexRIO transceiver features user-programmable FPGAs. Photo courtesy of National Instruments.


24

 

“This ability to abstract away different parts of your program is key, so that a change in one part of the test set does not force you to recertify other parts,” Butler states. “The better that you can compartmentalize or abstract or kind of modularize your test program sets, the better off you’ll be as you define through software and limit the amount of recertification overhead work that you have to do.”