​​Automate Early in Design and Validation: From First Trace to a Usable Test Application​

If automation is prioritized only when production begins, the downstream test engineering teams pay the price. Ad-hoc manual workflows create inconsistent results, hide race conditions, and force engineers to debug automation under schedule pressure. Worse, workarounds accumulate when instruments and devices are only controlled manually—and those shortcuts rarely survive automated use.

The fix is simple in concept and powerful in practice: make automation a first-class behavior during design and validation. Use interactive, test-optimized software with instruments designed to be automated so that first-trace work becomes repeatable and ready to evolve.

While many teams will rely on design engineers to create and maintain their own strategies and software for taking measurements, and then return to whatever has been created later to automate the tests, building the initial system with quality automation tools and tactics in mind has the following benefits: 

• Repeatability—Standard steps reduce day-to-day variability 
• Traceability—Metadata and saved configurations make results comparable across benches 
• Faster iteration—Reusable app patterns, easy UI creation, and saved profiles accelerate change 
• Fewer configuration mistakes—Templates and resets prevent mismatches 
• Better coverage—Early automation exposes edge cases that hand-driving often misses 
• Less rework—Design measurement software evolves into a structured application or sequencer instead of being thrown away 

To be clear, this is not a recommendation to avoid any manual testing, but more so an attempt to integrate an appropriate level of automation as an asset to prevent the very predictable negative downstream effects when automation is treated like a hindrance to going fast in design and validation. 

The test automation process can be broken down into the following high-level “phases” of automation. Sometimes it might be appropriate to complete only the first one, whereas for more complex applications, getting to the highest level of automation offers significant benefits. The automation process is made up of these steps: 

• Automation accelerators for interactive configuration and logging during bring-up  
• Rapid prototyping and measurement development to explore and characterize behaviors 
• Structured applications enabling broad automation characterization and logging 

Let’s walk through how to be successful with this workflow using NI software. 

Bring-Up and Logging with InstrumentStudio and FlexLogger 

Initial bring-up of a device can be a chaotic time. Commonly, engineers are preoccupied with understanding the many behaviors of their device—both expected and unexpected. InstrumentStudio allows users to configure and synchronize multiple instruments (oscilloscopes, SMUs, digital pattern) interactively. FlexLogger helps users set up transducer and DAQ-based channels (vibration, temperature, strain) to dynamically log mixed signals with rich metadata and a no/low-code interface. Both tools help teams move from interactive measurements to repeatable automation quickly without needing to start from a blank coding canvas, regardless of the intended language.  

These tools enable automation by taking the work done interactively and enabling the recreation of these complex configurations in software, usually in three API calls or less. Also, they take a “project” style approach to tasks, where a user is not just saving a single set of instrument settings to disk, but rather providing a system-level dashboard for all instruments and I/O, which accelerates later interactive sessions.  

Imagine for a moment that an engineer spent the greater part of an afternoon configuring the scope, DMM, spectrum analyzer, and SMU to catch turn-on transients in a device. How would they return to that same point later? How would they share that configuration with a colleague? How would they get a junior engineer to reproduce the process and have faith in the results?  

Now imagine the next day, the same user walks into the lab, opens a single file, and all their heterogeneous mix of test equipment is configured and ready to run. InstrumentStudio and FlexLogger deliver this seamless experience. 

Figure 1. InstrumentStudio showing instant interactive access to instrument configuration and analysis in a project-centric workspace

Our recommended bench bring-up checklist (hardware/platform agnostic and repeatability oriented) includes performing the following steps.  

1. Reset all instruments to known defaults—Persistent settings from prior runs can make it difficult to achieve repeatable measurements. Deterministic configurations are critical in the early stages when users can’t rely on the device to be consistent. 
2. Verify channel mappings and pinouts for digital I/O and analog signals—Many instruments enable name mappings from I/O on the device to port on an instrument which can make rapid development that much clearer and more traceable.  
3. Load standard instrument configurations from saved profiles—Are there specific configurations that have been defined already or which came from others? Based on the device type or test configuration being used, users may already be better prepared for the next steps. This significantly reduces the pain associated with  “resetting to defaults.” 
4. Check synchronization and timing across instruments—When users can leverage powerful features like instrument-to-instrument triggering, it’s always good to validate stable timing performance. This is even more important when users can send triggers and receive events from the device under test (DUT); variable firmware behaviors can wreck an optimized system if not tended to. 
5. Run a repeatability mini-test, execute the same steps twice, and compare traces—Before running large tests, making sure the results are in line with expectations, repeatable, and being logged properly can prevent major issues. All too often, automation is avoided because of historical failures based on copious amounts of bad data being recorded and days wasted. Users should have a specific suite of tests ready to validate before they automate. 
6. Log results to TDMS or CSV with the metadata template applied—Consistency is key when logging any data. If results cannot be compared or correlated across systems, or even across individual runs, the data loses practical value. Effective data harmonization depends on intentional decisions made from the very first trace. 
7. Save the setup snapshot: the InstrumentStudio project and FlexLogger configuration—Once results are taken, having a snapshot of the configuration that yielded those results can maximize the likelihood of reproducing and trusting results. Completing the connection between manual measurements and system data will enable future projects to use and compare those results more effectively. 

After the initial bring-up tasks are complete, it’s important to decide how data will be logged. The following list shows common metadata fields for test data: 

• Project ID, DUT ID or serial, firmware revision 
• Test name and version, operator, date and time, lab location 
• Instrument details: installed options, driver versions, model numbers, calibration status 
• Synchronization settings 
• Environmental conditions: temperature, humidity 
• Run tags—baseline or variant—and notes 

InstrumentStudio and FlexLogger can also run in parallel and comingle where it helps, which is sometimes referred to as a “braided workflow.” By configuring instruments and verifying timing in InstrumentStudio and logging synchronized DAQ channels with FlexLogger, the first traces are traceable and reusable. Fundamentally, each application provides different workflow acceleration, but the savvy engineer learns how and when each is best used—as well as how to take advantage of their extensibility to integrate I/O not enabled out of the box. For instance, InstrumentStudio commonly is associated with PXI modular instruments alone; however, users can create custom plug-ins to give themselves and their organizations a fully integrated experience within a single platform (DUT plug-ins, third-party instrument plug-ins, visualization plug-ins). 

Figure 2. FlexLogger showing a dynamically-created panel showcasing interactive DAQ configuration and logging

Rapid Prototyping and Measurement Development to Explore and Characterize Behaviors 

After the interactive process becomes more stable, the development of lightweight measurement automation applications is common. The best measurement apps are small applications that prototype quickly, reconfigure on the fly, and visualize outputs instantly. LabVIEW features seamless hardware integration, comprehensive processing libraries, and easy UI creation, allowing users to drag and drop controls, indicators, and graphs to assemble a usable test app quickly, as shown in Figure 3. The goal is to move beyond a single script while staying nimble.

Figure 3. A screenshot of an example test panel written in LabVIEW for rapid prototyping that has migrated into an InstrumentStudio Plug-In.

LabVIEW and NI Nigel™ AI can assist with structuring the automation app and using NI hardware features effectively, helping users reduce boilerplate and avoid common pitfalls while building. 

We recommend the following components as part of a suggested structure for the measurement apps. These are relevant considerations and not intended to be a comprehensive list: 

• Panel layout—These can be grouped by function and purpose. The placement of specific configuration values and measurement results enables accessibility and ease of use. Secondary configuration panes can also be used to display and modify variables and outputs that are not fundamental to the operation. 
• Controls—These include start and stop, test selection, setpoints, and logging toggle, along with profile save and load. 
• States—These include initialization, core configuration, parameter calculation, measurement loops, active logging, and teardown. 
• Error handling—This includes per-module error queues plus a summary indicator. 
• Data model—This provides TDMS logging with an in-memory ring buffer for live charts. 
• Reuse—Allows users to save and load test profiles, as well as version the app project. 

After the measurement applications are made useful and repeatable, decompose their behaviors into modules that can evolve into a structured application or a test sequencer. For example, a user could break the flow into initialization, core configuration, parameter calculation from user-declared inputs, measurement loops that actively log results and metadata, and reliable reporting. Templates for error handling, condition management, and reporting save time and reduce defects. 

There are some trade-offs to consider when a team might choose to stay interactive, code a test app, hand off to sequencing, or do all three: 

• Stay interactive—If one of the following situations is true, consider using only interactive software like InstrumentStudio or FlexLogger. 
  • Users only need one or two instruments 
  • Exploratory bring-up 
  • Single-operator work 
  • Basic snapshots of data or simple data logging 
• Code a LabVIEW test app—When your needs exceed the boundaries of interactive tools, LabVIEW provides a great option for building your own custom interactive experience or plug-in creation. This is commonly due to demands of processing, visualization, or multi-instrument interaction. 
  • Repeated runs 
  • Parameter sweeps 
  • Augmented logging and more than a basic UI 
  • Small team reuse 
• Hand off to sequencing—At some point the overall interaction of your platform warrants execution from an actual test executive, where the responsibility of overall automation and measurement automation are different layers. Software like NI TestStand is purpose-built for this phase of your automation needs. The following are some situations that might lead to using a test executive: 
  • Multiple DUTs or stations 
  • Parallel execution of sequences 
  • Formal software deployment 
  • Abstracted data logging and results tracing 

The LabVIEW+ Suite brings together the tools that reduce the friction of early automation and scale as needed: InstrumentStudio for instrument configuration and visualization, FlexLogger for sensor-centric logging with synchronization and metadata, and LabVIEW for interactive test apps and analysis with easy UI creation. When the time comes to adapt, expand, and deploy to an infrastructure for automation either in validation or production, other software within the suite, like NI TestStand and NI DIAdem, are ready to save development time and overall cost. Using software designed to work together and purpose-built for test and measurement offers a more reliable approach than building systems from scratch with general-purpose tools. 

The automation process discussed earlier can now be applied to illustrate how it might work for an example application. 

The device under test for this example is a smoke detector with lithium-based supply behavior, audible alarm, and environmental sensors. The test engineer must connect to an SMU battery simulator, oscilloscope or analog trigger, temperature, digital I/O, analog channels for humidity and carbon monoxide. For this scenario, it is assumed the team is using NI PXI modular instruments—such as oscilloscopes and SMUs—along with NI CompactDAQ modules for basic I/O and transducer-based signal acquisition. 

Phase 1: Interactive Acceleration Using Optimized-for-Automation Tools 

Engineers accustomed to working with bench instruments can easily transition to using the unified InstrumentStudio interface. With a single click, InstrumentStudio scans available PXI resources and automatically populates an instrument dashboard, giving users immediate access to begin developing measurements and experiments. 

For this example, the SMU, oscilloscope, and analog inputs are available for configuration and visualization. InstrumentStudio provides a front-panel experience and snapshot saving of data, while FlexLogger runs data logging over a period of time, capturing certain conditions of the CompactDAQ I/O by default. InstrumentStudio powers up the board with the SMU, scope probes various signals and ports to ensure correct values and behaviors, and also monitors various analog signals during that process. After that step is completed, the team may want to conduct tests across various environmental conditions, at which point they would begin using FlexLogger to configure additional electromechanical signal acquisition. For each application, the configuration is project-based, and by simply saving the project, the team creates a starting point for future tests—either for themselves or for others. 

Phase 2: Automation-Enabled Measurement Scripts and Utilities 

After establishing the proper configuration to execute tests, the exported and saved configurations can be used within simple scripts and programs. NI PXI instrumentation can seamlessly import those configuration files created from InstrumentStudio to instantly bring the hardware into a known state. Then the team can begin developing simple measurements that programmatically adjust, sweep and execute the needed tests with a blend of custom UI interactivity and visualization and simplified creation.  

For data-logging sessions, FlexLogger can be automated directly from API calls giving the test engineer the ability to go beyond any limitations they may have encountered using the wide range of features that FlexLogger provides by default. NI software enables users to begin work quickly and allows them to extend its capabilities to meet their specific requirements rather than limiting them to fixed functionality. 

Phase 3: Formalized Automation Integration 

Depending on the level of automation maturity of an organization, establishing guidelines and tools for transitioning to this next phase may be critical. However, when engineers leverage hardware and software optimized for full automation, progress can be smoothly achieved. For example, if measurements created in the previous stage adopt a policy of strong functional boundaries, then it is possible to separate measurement configuration from instrument execution and processing and fit into the measurement plug-in framework for InstrumentStudio and FlexLogger. If FlexLogger has been properly leveraged, extending your data sources, data processors, or data sinks to your test system will enable your complete logging needs with the lowest level of code creation possible. The test team can consider the following recommendations: 

• Decompose the utility into modules that handle initialization, configuration, parameter calculation, measurement loops, and logging. 
• Adopt templates for error handling and condition management; prepare reporting steps. 
• Hand off to a test sequencer if parallelization or multi-station execution is required.

Figure 4. Characteristic electronics device as smoke detector PCB during the production cycle.

Prioritizing automation early in the engineering lifecycle consistently pays dividends—teams that integrate automation from the first trace to reduce rework, gain repeatability, and accelerate iteration. By relying on software built specifically for test and measurement, paired with hardware designed to automate, engineers unlock measurable efficiency and avoid the pitfalls of improvised, manual‑first workflows. And instead of assembling a patchwork of DIY tools, using a cohesive software suite from a trusted provider ensures interoperability, reduces technical risk, and positions teams to scale from exploratory bring‑up all the way to structured applications and full sequencing. Early, intentional automation isn’t just a best practice—it’s a strategic advantage that compounds across every phase of design and validation. 

• Request a LabVIEW+ Suite Demo
• Watch the on-demand webinar, Quick Test Setup, Seamless Automation
• Learn about other ways to level up your test automation