The development platform for industrial systems

A typical PCB functional test station uses a DMM, SMU, oscilloscope, power supply, switch matrix, and barcode scanner. In a traditional setup, each instrument driver is wired directly into the test sequence. Swapping the DMM from a Keysight 34461A to a Fluke 8845A means editing every step that calls the DMM driver, revalidating the sequence, and repeating that work on every station that runs the same program.

With S1 Foundry, the test sequence calls the DMM module contract. The switch matrix module handles relay routing. The barcode module captures serial numbers. All six instruments connect through the gateway, which provides a single diagnostic stream showing every command, response, and timing across all instruments simultaneously. When the DMM is swapped, only the module map entry changes. The test sequence, limits, and reports are untouched.

The results bus inside the gateway pushes structured test records (serial number, test name, measured value, limits, pass/fail, operator, fixture ID, timestamp) to the MES or historian in real time. No post-processing scripts, no CSV exports, no manual uploads.

Testing power inverters, motor drives, or EV chargers means working with dangerous voltages. The test sequence must verify every safety interlock (enclosure door, e-stop, ground continuity, HV contactor state) before issuing any high-voltage command. If any interlock opens during a test, the system must discharge immediately.

In a traditional setup, the safety logic is often embedded in the test sequence itself, mixed in with measurement code. This creates two problems: the safety checks are only as reliable as the test programmer's diligence, and they are duplicated (with slight variations) across every sequence that uses high voltage.

With S1 Foundry, the safety PLC module monitors interlock state continuously. The gateway enforces a precondition: no HV command is routed to the power supply module unless the safety module confirms all interlocks are closed. This enforcement happens at the gateway level, not in the test sequence. It cannot be accidentally bypassed by a sequence edit. If an interlock opens mid-test, the gateway triggers the discharge sequence through the power supply module before the test logic even processes the event.

The power analyzer module captures efficiency, THD, and power factor measurements. The gateway correlates these with the DC bus voltage and AC load profile to build a complete efficiency map. All data flows to the results bus with the DUT serial number, so the quality system has full traceability without any manual data handling.

End-of-line testing typically involves multiple stations: electrical verification, thermal cycling, functional test, and final inspection. Each station has its own instruments, but they often share calibration data, test limits, and reporting targets.

Without S1 Foundry, each station maintains its own instrument calibration files, its own driver versions, and its own connection to the MES. When a DMM is recalibrated or replaced, the calibration data must be updated on every station that references that instrument model. This is error-prone and creates drift between stations that are supposed to produce identical results.

With S1 Foundry, calibration data lives in a shared store that every gateway instance references. When a DMM is recalibrated, the correction factors update in one place. Every station that uses the DMM module contract picks up the new calibration automatically on the next measurement cycle. Module versions are also centrally managed: when a handler update is qualified, it rolls out to all stations through the gateway's live update mechanism.

The MES integration is also centralized. Each station pushes results through its local gateway instance, but the results schema is identical because the same module contracts produce the same output structure. Serial routing (which DUT goes to which station next) is managed through the MES module, so the production flow is visible and controllable from one system.

Validating a wireless module, radar front-end, or mixed-signal ASIC requires instruments from three different worlds: RF (signal generators, spectrum analyzers, VNAs), digital (logic analyzers, pattern generators, protocol analyzers), and power (supplies, electronic loads, power analyzers). Each domain has its own vendor ecosystem, transport protocols, and measurement conventions.

In a traditional setup, these three domains are essentially three separate test systems bolted together. The RF engineer writes RF tests with Keysight IO Libraries. The digital engineer uses Tektronix OpenChoice. The power engineer writes custom SCPI scripts. Correlating results across domains (e.g., “what was the DC power consumption when the RF output hit -3 dBm?”) requires manual timestamp alignment across three different data sets.

With S1 Foundry, all three domains run through the same gateway. The cross-domain correlation engine inside the gateway timestamps every command and response on a common clock. The test sequence can issue an RF measurement and a power measurement in the same step, and the gateway returns both results with synchronized timing. This makes it straightforward to build efficiency curves, thermal derating profiles, and spectral-vs-load characterizations without post-processing.

When the RF test team upgrades from an older spectrum analyzer to a newer model, only the spectrum analyzer module map entry changes. The digital and power modules are completely unaffected. The validation sequence, correlation logic, and reporting all remain identical.

Environmental stress screening (ESS) runs DUTs through temperature cycling, humidity, and vibration profiles that last 24 to 168 hours. During this time, the test system must continuously monitor the DUT (resistance, leakage current, functional response) while controlling the chamber profile and logging environmental conditions.

The challenge is reliability over time. A 72-hour burn-in test that crashes at hour 60 wastes three days of chamber time, three days of DUT availability, and three days of data. Traditional test systems are not built for multi-day unattended operation. A memory leak in a driver, a dropped USB connection, or an OS update that triggers a reboot can end the test silently.

The S1 Gateway is designed for this. Each module runs in its own process, so a DAQ driver that leaks memory over 48 hours gets caught by the gateway's health monitor and restarted without affecting the chamber control module or the DMM module. The chamber profile continues uninterrupted. The measurement gap is one restart cycle (typically under 5 seconds), and the gateway logs it so the data analysis knows exactly which interval was affected.

The continuous health check inside the gateway monitors all module processes for memory growth, response time degradation, and communication errors. If a module's response time starts trending upward (a common sign of resource exhaustion), the gateway can preemptively restart it during the next soak period rather than waiting for it to fail during a critical measurement window.

Every module runs as an isolated OS process managed by the S1 Gateway. The gateway owns the process lifecycle: it starts modules in dependency order, monitors heartbeats, and restarts any module that stops responding or crashes.

This means a faulty GPIB driver cannot hang the test executive. It cannot corrupt state in other modules. It cannot prevent the operator from continuing with the remaining instruments. The gateway terminates the unresponsive process, logs the failure with full context (module name, instrument address, last command issued), and brings up a fresh instance. Test logic sees a recoverable error, not a station-wide failure.

Traditional architectures run all instrument drivers inside the same process as the test executive. A single driver fault (memory leak, unhandled exception, communication timeout that blocks a thread) can freeze or crash the entire station. Diagnosing these failures is difficult because the crash dump mixes state from every driver, the executive, and the application logic.

Each module exposes a typed contract: a set of operations (e.g., ConfigureMeasurement, ReadValue, SetOutput) with defined input/output schemas. The contract is the same regardless of which instrument sits behind it.

When a Keysight 34461A DMM is replaced with a Fluke 8845A, the test program does not change. The module map (a JSON configuration file) points the DMM contract to the new instrument handler. The handler translates contract calls into the vendor-specific SCPI commands, IVI calls, or proprietary protocol sequences that the physical instrument expects.

S1 Foundry ships handlers for 100+ instrument vendors. Each handler is regression-tested against the instrument's documented command set. When a handler is updated (new firmware support, bug fix, performance improvement), it is deployed as a module update through the gateway without restarting the station or interrupting running sequences.

Modules communicate through the gateway's message bus, not through direct inter-process calls. Every message (command, response, event, diagnostic) is routed through the gateway, which provides:

• Observability. All traffic between test logic and instruments is visible in one diagnostic stream. Timing, payloads, and error codes are captured without instrumenting individual drivers.
• Rate limiting and back-pressure. The gateway can throttle commands to instruments that cannot handle burst traffic (common with serial protocols like RS-232 and GPIB).
• Transport abstraction. Test logic connects to the gateway over the same API whether the instrument is on TCPIP, USB, GPIB, serial, PXI, or a fieldbus protocol. The transport layer is the handler's concern, not the test program's.

External systems (MES, SCADA, historians, operator HMIs) connect to the gateway through its service surface: REST, WebSocket, gRPC, or GraphQL. Results, events, and station state are published without polling.

The gateway supports hot-swapping modules while the station is running. The sequence is:

1. The new module version is staged on the gateway host.
2. The gateway waits for the target module to reach an idle state (no in-flight commands).
3. The old module process is gracefully shut down. In-progress measurements complete; no commands are dropped.
4. The new module process starts and re-establishes the instrument connection.
5. The gateway routes subsequent commands to the new process. Test logic is unaware of the swap.

This is how driver updates, handler bug fixes, and configuration changes reach production stations without scheduling downtime. It is also how instrument swaps work: the module map changes, the handler process restarts with the new target address, and the contract remains identical.

The gateway distinguishes between transient and permanent failures:

• Transient: communication timeout, instrument busy, buffer overflow. The gateway retries with configurable back-off. If recovery succeeds, the test sequence continues without operator intervention.
• Permanent: process crash, instrument disconnected, repeated timeout after retry exhaustion. The gateway marks the module as faulted, logs a structured diagnostic record, and notifies test logic through the error channel.

Diagnostic records include the module identity, instrument address, transport protocol, the command that triggered the failure, timing data, and the raw error from the instrument or OS. These records feed into the gateway's diagnostic API, which external monitoring systems can subscribe to.

In traditional architectures, diagnosing “the station hung” requires correlating logs from the test executive, the driver layer, the OS event log, and sometimes a packet capture. In S1 Foundry, the gateway already has the full timeline because every command passed through it.

S1 Foundry provides 444 TestStand step types across 47 palettes. Each step type maps to a module contract operation. When a step executes, TestStand calls the S1 Gateway through a .NET adapter assembly, which routes the command to the appropriate module process.

From TestStand's perspective, S1 modules behave like any other code module: they accept parameters, return results, and report errors through the standard TestStand error mechanism. The difference is that the instrument driver, transport, error handling, and diagnostics are managed by the gateway rather than by code inside the TestStand process.

This means existing validated TestStand sequences can adopt S1 modules incrementally. Replace one instrument call at a time. The sequence structure, limits, flow control, and reporting remain untouched. The validation scope of the change is limited to the module configuration, not the test logic.