Develop and run industrial test systems

A PCB functional test station may use a DMM, SMU, oscilloscope, power supply, switch matrix and barcode scanner. When sequences call vendor drivers directly, replacing an instrument can require edits to several test steps and a review of the affected stations.

With S1 Foundry, the sequence calls instrument modules through common interfaces. Separate modules handle measurements, relay routing and serial-number capture, with diagnostics collected through the gateway. A compatible DMM replacement can be selected in the module map. Confirm measurement range, accuracy, timing and calibration before reusing the sequence.

The results bus sends structured test records to a connected MES or historian. Records include the serial number, test name, measured value, limits, pass/fail result, operator, fixture ID and timestamp.

Testing power inverters, motor drives and EV chargers involves hazardous voltages. The station needs an independently engineered safety system covering interlocks, emergency stops and the required safe state. Those requirements follow from the equipment risk assessment, not from the test sequence alone.

S1 Foundry can integrate status from a safety PLC and use it as an additional condition for issuing test commands. Keeping these checks separate from measurement code makes the test application easier to review and maintain.

Gateway checks and software-controlled discharge are not substitutes for safety-rated interlocks or protective functions. Loss of communication, module failures and stale status must be addressed by the station safety design. This example describes test coordination, not a certified safety function.

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.

Separately maintained station configurations can diverge over time. Driver versions, calibration records and MES connections need a defined update process so that measurements and results remain comparable across stations.

A shared calibration store lets stations retrieve approved data for the specific instrument in use. Calibration records and correction factors must remain associated with that instrument, not just its model or module type. Qualified module updates can be distributed through the gateway under a controlled rollout.

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.

Separate RF, digital and power test tools may record results using different clocks and formats. Correlating those results requires a defined timing and data model, particularly when measurements need to describe the same operating condition.

S1 Foundry connects the instrument groups through the same gateway and records command and response timing. A sequence can request RF and power measurements together and combine their results. Gateway timestamps alone do not establish simultaneous acquisition; check instrument triggering, clocks and transport delays against the required timing accuracy.

Replacing a spectrum analyser can be handled through its module map when the new model supports the required operations. Review measurement settings and timing before reusing the validation sequence and correlation logic.

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.

Long-running tests need a plan for driver faults, lost connections and host restarts. An interruption late in a burn-in cycle can require substantial retesting, so the system must record faults and distinguish valid measurements from gaps in the data.

The S1 Gateway monitors module health and can restart a failed DAQ process independently of the chamber and DMM processes. Recovery time depends on the driver and equipment. The application must record measurement gaps and determine whether the chamber programme can continue or the test needs to stop.

Module health and diagnostics help identify memory growth, slow responses and communication errors. Use those observations to plan maintenance and recovery around the test profile rather than assuming every restart is harmless.

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.

A driver process has a separate memory space from the test executive and other modules. The gateway can terminate an unresponsive process, log its module identity, instrument address and last command, and start a new instance. Whether testing can continue depends on the failed instrument and the application recovery logic.

When drivers and test logic share a process, a memory fault or unhandled exception can affect the whole application. Separate processes make the affected component easier to identify and restart, while dependencies between components still need explicit error handling.

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.

The module map is a JSON configuration file that selects the handler behind an instrument interface. A DMM handler translates measurement calls into the SCPI commands, IVI calls or other protocol operations required by its instrument. Compatible instruments can share the test logic, subject to their measurement capabilities and validation requirements.

S1 Foundry includes handlers for 100+ instrument vendors, with regression tests against documented command sets. Handler updates are deployed through the gateway. Coordinate the update with any running sequences that depend on the affected instrument.

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 shut down after it reaches an idle state. Active measurements and pending commands need application-specific handling.
4. The new module process starts and re-establishes the instrument connection.
5. The gateway routes subsequent commands to the new process through the same interface.

This process updates a module without restarting the gateway. Instrument replacement also involves updating the module map and restarting the handler with the new target address. Assess the effect on active test steps and verify the replacement before returning the station to production.

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.

Existing TestStand sequences can adopt S1 modules incrementally, replacing one instrument call at a time. Retain sequence structure, limits and reporting where appropriate, and determine the validation scope under your existing change-control process.