Hardware test data platforms: Nominal, Sift, Synnax, and where test execution fits

Nominal, Sift and Synnax are data platforms for hardware test: they collect and store test telemetry and help engineers review it. They differ in how far each reaches toward the bench. Sift ingests and reviews data. Nominal adds Connect, an edge framework for Python test apps. Synnax acquires data and controls NI, LabJack and EtherCAT hardware itself.

Running a test against bench instruments, with a versioned procedure, limits and a verdict per step, is a separate layer. This post compares the three from their own documentation, then shows where execution sits and how the layers connect.

What is a hardware test data platform?

A test produces signals: pressures, temperatures, voltages, currents, bus traffic, logs and video. A test data platform ingests them, streamed live or imported as files, indexes them by the hardware under test and the run, and gives engineers plots, derived signals and automated checks across runs.

Sift's data model is a clear statement of the idea. An Asset is "the system, vehicle, or test article you are examining," a Channel is one of "the signals or measurements you care about," and a Run is "the recording session, test, or mission where that data was captured." Synnax organizes data with channels, ranges and projects; the vocabulary differs, the shape does not.

The unit of record is a channel: a named signal sampled over time. A test executive keeps a different unit, a step: one measurement against one limit, with a verdict, on one serial number, under one version of the procedure. The platform answers "what did this signal do, and how does it compare with the last fifty runs?" The executive answers "did unit SN-0193 pass step 12 of procedure version 7, and what was the reading?" Most programs need both, joined by shared keys.

Nominal vs Sift vs Synnax: how do they compare?

Rows are layers of the stack, from the instrument up; cells paraphrase each vendor's documentation.

What does Nominal do?

Nominal calls itself "the unified software suite to test and operate hardware" and sells two products that split along the line this post draws.

Nominal Core is "the all-in-one data platform for hardware engineering." In Nominal's words, it lets teams "capture and monitor telemetry, logs, video, and simulation results" and "execute trend analysis over time." In April 2026 Nominal announced it is acquiring Fid Labs, whose first product, an AI Analyst that "lives inside Nominal Core," it said "ships soon."

Nominal Connect is "the edge compute platform for hardware test". It "runs at the edge, reading from and writing to instruments in real time," so engineers can "capture data, control hardware, and sequence repeatable tests, all from Python." The homepage describes the split directly: "Connect executes tests locally with deterministic timing and local UIs while streaming results to Core for deeper analysis."

Two pieces are open source under Apache-2.0. Instro is "an open-source, vendor-agnostic Python library for interfacing with test equipment," with generic classes such as InstroPSU, InstroDMM, InstroScope and InstroDAQ over drivers from Keysight, Rigol, Siglent, B&K Precision, NI-DAQmx, LabJack and others. Nominal's post on Instro describes it as a hardware abstraction layer where you "swap the actual hardware driver under the hood with a one-line code change," with a built-in SCPI simulator. The Python client installs with pip install nominal.

Nominal says to "run Core in secure clouds, private environments, or on-prem" and "run Connect where the hardware lives," from lab benches to air-gapped facilities.

Nominal covers both layers this post separates.

What does Sift do?

Sift's site calls it an "Observability Platform for Mission-Critical Hardware", and its documentation sums up the job as "Ingest telemetry. Define checks. Automate reviews."

Ingest. Live data streams over gRPC through Sift's client libraries for Python (sift_client, from the sift-stack-py package), Go and Rust. Recorded data comes in as files: the UI imports CSV, Parquet, TDMS, HDF5, ULog and MCAP. TDMS is NI's file format, so files from NI-based stations import without conversion.

Review. A Rule is a Common Expression Language (CEL) condition over one or more channels, such as $1 > 120 for a motor temperature. "Sift evaluates the Rule against a Run when you generate a Report," and each time the expression is true it creates an Annotation. Rules are reusable across runs and report templates. Where the acceptable range moves from test to test, Family Rules compare a run with a historical baseline instead of a fixed limit. Campaigns track a review across many runs.

Test results. Sift's API also has a test report service. A report carries the DUT serial, test case, operator and run ID; its steps hold measurements with numeric or string bounds and a passed flag.

Deploy. Sift's platform page says teams can "deploy on-prem, in private cloud, or in GovCloud" and that "air-gapped and low-bandwidth environments stay fully supported." Its trust page states that Sift meets all 110 security controls of NIST SP 800-171.

Sift's design center is what happens after the data exists. The test runs in whatever software the team already has, which streams or uploads into Sift.

What does Synnax do?

Synnax describes itself as "a sensor data platform that handles everything from collecting measurements off your hardware to storing, visualizing, and acting on them in real time." It has three parts: Core, the server; Console, the user interface; and the Driver.

Acquire and control. The Driver "reads and controls hardware from National Instruments, LabJack, and EtherCAT devices" and "acquires data from servers over HTTP JSON REST APIs, Modbus TCP/IP, and OPC UA." It runs inside Core or as a separate binary on another machine, including NI Linux Real-Time controllers such as CompactRIO and PXI systems.

Automate. Control sequences come in two forms. Arc is Synnax's reactive automation language, with visual and text modes; it runs on the Driver, including on NI Linux Real-Time, so control loops run next to the hardware. Python sequences "run externally and communicate with Synnax over the network," and Synnax's guidance is to use Python for flexibility and Arc for "consistent, low-latency control." The documented example is bang-bang control: open a valve when pressure falls below a threshold, close it otherwise. Console dashboards add real-time monitoring and manual control, and Python and TypeScript clients read, write and stream data.

Deploy and license. Core is self-hosted: the quick start covers Linux, Windows, macOS and a Docker image. The source is on GitHub under the Business Source License 1.1, which says of itself that it "is not an Open Source license" but that the licensed work "will eventually be made available under an Open Source License." The file covers "Synnax version 0," allows use "with a total of less than three server instances for any purpose," and names April 1, 2026 as the change date, after which it grants rights under Apache 2.0. That date has passed. The license lets each version carry its own change date, so confirm with Synnax which terms cover the release you deploy.

Synnax is built for rigs where the test is acquisition plus actuation: DAQ channels, valves, PLCs and real-time loops.

What are the alternatives to Nominal?

The answer depends on which half of Nominal you are replacing.

• Core's role, storing and reviewing telemetry: Sift, if you want rule-based review and government or air-gapped deployment, or Synnax, if you want to self-host and your data comes from DAQ, PLC or industrial-protocol hardware.
• Connect's role, running tests at the bench: Synnax control sequences for DAQ-and-actuator rigs; a Python framework such as OpenHTF, or pytest with PyVISA, if you want to own the code (our TestStand alternatives post compares them); or a test executive such as Galois.
• Instro's role, the driver layer: PyVISA with your own driver classes, as in our SCPI automation guide, or one of the libraries in open-source instrument control software, compared.

Where do test execution and instrument control sit?

Between the instrument and the data platform sit two layers.

Instrument I/O is the driver: SCPI over VISA, a DAQ driver, Modbus registers, a vendor SDK. It turns "set 5 V, measure current" into bytes on a bus.

Test execution decides what happens and records whether it passed. It owns:

• The procedure and its version. Which steps run, in what order, against which limits, and which approved revision is allowed on the bench.
• The verdict. Each measurement compared with its limit and marked pass or fail, so a failed unit is a fact rather than a plot someone has to read.
• Identity. Operator, DUT serial, instrument identity and timestamps on every result.
• Instrument ownership. One owner per instrument while a transaction runs, so two programs never interleave commands on the same supply. The SCPI guide explains why that matters.

Galois works in these two layers. The galois-edge daemon handles I/O, and Galois ships 573 instrument profiles across 135 manufacturers (instrument library); when an instrument has no profile, Évariste generates one from the instrument's programming manual. Sequences are built from typed steps such as Numeric Limit, Measure, Loop and Sequence Call. A draft cannot run until an engineer approves it, and an edited sequence must be approved again. Every step records the measured value, limits, raw command and response, instrument ID, operator, DUT serial and timestamp (product). The traceability post follows that record from requirement to run.

In Galois, an engineer can do that work through Évariste. Open it beside a project (Ctrl+Shift+E), ask "List connected instruments" to find the SMU that powers unit SN-0193, then state the objective and its limit: measure the unit's supply current and fail any reading above 120 mA, the maximum in the DUT datasheet's supply-current row. Évariste drafts a versioned sequence from the SMU's profile, and the draft cannot run until an engineer reviews and approves it. Once approved, it runs on the bench through galois-edge with channels live in Monitor, and each step is recorded as described above. Afterward, ask which steps failed or passed close to the limit, compare the run with earlier units, or say "Generate a test report from the last run." The driver class, step loop, error handling, logging and report script are no longer yours to write. Stating the objective and limit, approving the draft, confirming any dangerous command Évariste sends straight to an instrument, wiring the bench and keeping it safe stay yours. Getting the readings into Sift, Nominal or Synnax follows the fourth convention below.

The boundary is a design center, not a wall. Nominal Connect and Synnax sequences execute tests, and Sift's test reports store step verdicts. Galois streams readings into live dashboards and keeps snapshots of measurements. The difference is the shape of the record: an executive organizes it around steps and verdicts, and a data platform organizes it around channels over time.

How do a test executive and a data platform work together?

Four conventions keep the two records joined.

1. One owner per instrument. If Synnax drives the DAQ and valves while a test executive drives the SCPI supply and DMM, write down which program owns which instrument, and never let both touch the same one.
2. Shared keys. Put the run ID, DUT serial and procedure version on both sides, as run metadata in the platform and on the run in the executive. A reviewer looking at a failed step can then open the telemetry around it.
3. One clock. Record timestamps in UTC with the time source noted. A 200 ms offset is enough to misplace a step against a transient.
4. Neutral formats. Move data as files the platform imports, or through its client library, rather than through a format only one side can read.

The fourth convention in code: stream supply current through the Galois Python SDK and write a Parquet file for Sift's file import.

# pip install pandas pyarrow; install the Galois SDK per docs.galoislabs.ai/guides/python-sdk/
import galois
import pandas as pd
 
RUN_ID, DUT_SERIAL = "R-0042", "SN-0193"
 
points = []
with galois.Edge.connect("lab-pi:50051") as edge:
    smu = edge.instrument("GPIB0::24::INSTR")
    with smu.stream("measure_current", interval_ms=200) as stream:
        for point in stream:
            points.append((point.timestamp_ms, point.value))
            if len(points) == 300:  # 60 s at 200 ms; leaving the block stops the stream
                break
 
df = pd.DataFrame(points, columns=["timestamp_ms", "supply_current"])
df["time"] = pd.to_datetime(df["timestamp_ms"], unit="ms", utc=True)
df[["time", "supply_current"]].to_parquet(f"{RUN_ID}_{DUT_SERIAL}_supply_current.parquet", index=False)

The run ID and serial travel in the file name here; on import, attach them to the Run so both systems share the key. Nominal's and Synnax's Python clients also write data programmatically, so the same points can reach either platform without a file.

The verdicts stay in the executive. If the platform needs them, send a summary, one row per step with value, limits and pass or fail, rather than rebuilding limit logic in two places. Sift's test report API takes that shape directly.

When is Nominal, Sift or Synnax the better choice?

A test executive does not replace any of these platforms, and each is the better choice for some teams.

Choose Nominal when you want edge test apps and the data platform from one vendor, your engineers write Python, and the data spans telemetry, logs, video and simulation. Instro's open-source drivers give the bench layer a starting point you can read and extend.

Choose Sift when the work is reviewing large volumes of telemetry across vehicles, stands and runs, and you want every run checked against the same rules before anyone signs off. It is also a strong fit when deployment has to be GovCloud, on-prem or air-gapped, or when existing stations already write TDMS, Parquet or CSV.

Choose Synnax when the rig is DAQ and actuation, such as NI cRIO or PXI, LabJack, EtherCAT, valves and pressure loops, and control has to run close to the hardware. Arc on NI Linux Real-Time is designed for that, and a self-hosted Core keeps data on your machines.

Choose a test executive such as Galois when the work is writing and running bench tests against SCPI and Modbus instruments, with limits, versions and approvals, and you want Évariste to draft the tests and drivers. Pair it with a data platform when the program also needs fleet-wide telemetry review.

You may need neither yet if one engineer owns one bench and a pytest harness writing files is keeping up.

The Sift comparison and Synnax comparison set the products side by side with Galois, and the full comparison index covers NI, Keysight and the rest. For where agents fit in test execution, read test sequencers vs test agents; for deployment options, see deployment.