LabVIEW DISCUSSION

What does a LabVIEW build SBOM tell us about a measurement application?

Started by subrat LabVIEW SBOMdependency trackingsoftware releasesdriver compatibilitytest systems
3 replies 248 views 4 participants
Latest activity · 27 Sep 2026

What does a LabVIEW build SBOM tell us about a measurement application?

subrat LabVIEW Forum
#1

The LabVIEW 2026 Q3 announcement describes an optional SBOM generation step for application builds. How should that fit into a test-system release archive?

What questions can a software bill of materials answer, and what still needs a hardware configuration record or an actual regression test before the application is installed on another measurement station?

Reference: NI: LabVIEW 2026 Q3 announcement (https://forums.ni.com/t5/LabVIEW/Announcing-LabVIEW-2026-Q3/m-p/4482202).

Community replies 3

Re: What does a LabVIEW build SBOM tell us about a measurement application?

#2

An SBOM records software components within its defined coverage. It can help identify which packaged dependency versions were included and support later maintenance review. Read the generated document and understand what the tool inventories; do not assume it describes every driver, operating-system component or external service used by the test station.

Re: What does a LabVIEW build SBOM tell us about a measurement application?

#3

Keep a separate station manifest for hardware models, firmware, drivers, operating system, runtime and calibration information. Include channel mappings and configuration files that affect measurement interpretation. Two stations running the same executable can produce different results if they use different sensor scaling or wiring. Dependency inventory does not establish measurement equivalence.

Re: What does a LabVIEW build SBOM tell us about a measurement application?

#4

Archive the SBOM with the build identifier, installer hashes and regression-test results. Test the application on a representative clean station, including missing-device and communication-failure cases. The inventory helps explain what was built; functional tests establish what it does under specified conditions. Both are useful when deciding whether a later package or driver update is acceptable.

TEP COMMUNITY