A simulated instrument can exercise test software without physical hardware, which is useful during development. The same capability becomes a problem if a production run treats generated data as measurements from a board. Define simulation as an explicit operating mode with distinct result handling.

NI’s DAQmx feature documentation describes simulated devices that support task verification without the corresponding physical hardware. Such verification is valuable for software development, but it does not establish the electrical behavior of the connected product.

Identify every simulation path

List simulated drivers, mock services, prerecorded waveform replay, forced step results, and bypass flags used by the application. Simulation may exist above or below the instrument interface, so checking only the driver name can miss a software-level substitution.

Give the execution mode a controlled source and show it clearly in the operator interface. Do not hide it in an obscure configuration file that is copied from a developer’s computer to the production station.

Separate configuration from evidence

Layer Check
Configuration Which mode was requested?
Runtime resources Which actual or simulated devices were opened?
Measurement source Was the value acquired, generated, or replayed?
Result storage Can downstream systems identify nonproduction data?

Record simulation status with each relevant run. A folder name alone is not reliable if files are later imported into a shared database. The record should carry its own source and mode information through the complete reporting path. Confirm that dashboards preserve this distinction when aggregating runs from several stations.

Validate the production gate

  1. Run the application with the intended physical resources.
  2. Attempt a production start with a simulated dependency.
  3. Check behavior when required hardware is unavailable.
  4. Verify that development records remain distinguishable.
  5. Review the released station configuration.

Do not automatically switch to simulation when a device fails to connect. That may keep a demonstration running but defeats production acceptance. Hardware unavailability should produce the defined station error or hold condition.

Retain simulation for useful regression tests, including abnormal values and communication failures that are difficult to reproduce physically. Label those tests as software validation and preserve their expected outcomes separately from product test evidence.

When moving from development to production, verify the complete dependency chain and result destination. A real instrument in one step does not prove that every other step uses real data. The goal is a production record whose measurements can be traced to the intended physical acquisition, with simulation available under an unmistakably different mode.

Move from reading to a build-ready project

Use the fabrication and assembly checklists to prepare drawings, production files and test requirements.

Open the DFM checklist