Application Patterns Never Go Out of Style

Over the last year and a half, I've had the pleasure of working with the JKI team and reconnecting with the LabVIEW community. For those of you who don't know me, I spent 25 years at NI (1996–2020), where I had the opportunity to work alongside some incredibly talented people, both inside the company and throughout the measurement and control industry.

One of the things that has struck me during my time with JKI is a fundamental truth about our industry. Technology continues to move forward. We have faster processors, modern frameworks, AI-assisted development, improved cybersecurity, DevOps, CI/CD pipelines, and better software engineering tools than ever before.

But despite all of that progress, measurement and control applications still follow a relatively small set of fundamental application patterns.

This way of thinking about measurement and control software was championed around 2007–2008 by Jenifer Loy while we were both at NI. Jenifer did an outstanding job of helping engineers recognize that, regardless of the industry or hardware, most applications are built from a relatively small number of reusable software patterns. That perspective has stayed with me throughout my career and is just as relevant today as it was then.

Every application we build is really some combination of these patterns.

I won't dive too deeply into each one here, but you've probably heard many of them before:

• Acquire – Analyze – Present – the classic data acquisition application.
• Sense – Think – Do – the control systems pattern popularized through robotics and autonomous systems.
• Stimulus–Response – common in electronics test.
• Software-controlled Sequencing.
• Event-driven Sequencing.
• Continuous Monitoring.

These patterns appear over and over again, regardless of the industry or technology. Once you begin looking for them, you see them everywhere. It's one of my favorite topics to discuss because it simplifies what can initially seem like an endless variety of applications.

One area where JKI has been especially active over the past decade is what I call real-time test applications. These are the systems responsible for orchestrating an entire test cell: coordinating control systems, sequencing, operator interfaces, safety systems, data acquisition, and real-time analysis.

Over the last 18 months, I've had the opportunity to work with customers building remarkably different systems that all rely on fundamentally the same software architecture. We've seen these patterns successfully applied at NASA's Arc Jet facility, hot-fire rocket test stands, high-velocity ballistics ranges, and electric vehicle drivetrain test cells.

While each facility is unique, one of the biggest commonalities is the need to continuously coordinate and monitor the entire test cell. Before any testing begins, the software must ensure that the facility is operating correctly, safety systems are armed, environmental conditions are within limits, control loops are stable, and every subsystem is ready. This is where the Continuous Monitoring and Sense – Think – Do patterns work together. Sometimes the response is as simple as opening a valve, changing a setpoint, or adjusting a control loop. Those actions are simply a natural extension of the monitoring pattern.

Once the facility is stable and ready, the magic begins.

Whether it's a rocket engine firing, a ballistic projectile traveling downrange, a plasma wind tunnel producing a hypersonic flow, or an electric vehicle drivetrain beginning a test cycle, these events often last only seconds, or even milliseconds, or as long as hours or days. During that window, the system must synchronize dozens or hundreds of channels or more, trigger instrumentation with precise timing, execute deterministic control, collect every required measurement, and do it all with exceptional reliability.

These tests are expensive. The data collected is the entire reason the test exists. Lost data means a wasted test campaign. Even worse, inaccurate or incomplete data can lead engineers to make incorrect design decisions.

Although the physical systems couldn't be more different, the underlying software architecture is remarkably similar. Time and again, we've found that these applications are simply different combinations of the same fundamental software patterns working together.

In future articles, I'd like to explore these real-time test architectures in more detail, discuss why they have proven so successful across so many industries, and share some of the architectural lessons we've learned along the way.

I'd also love to hear from you. Are you building measurement, control, or real-time test systems? Have you found yourself using these same application patterns? One of the best parts of reconnecting with the LabVIEW community has been the opportunity to exchange ideas with engineers solving some truly fascinating problems. I hope we get the chance to continue that conversation.