IN Brief:
- Remote Gateway exposes Pickering PXI and PXIe driver functions through a gRPC Device Server on the instrument host.
- Windows and Linux servers use Protocol Buffers interfaces accessible from languages including Python, C#, Go and Java.
- Remote clients do not require the Pickering driver stack; supported modules remain controlled through their existing host drivers.
Pickering Interfaces has introduced Remote Gateway software that allows applications on separate computers to control supported PXI and PXIe switching and simulation modules. The gateway runs a gRPC Device Server alongside the Pickering drivers on the host PC or embedded controller. Remote clients send commands across a network, leaving the existing driver stack and physical test hardware at the rack.
The gateway exposes functions from Pickering’s current driver API, so a remote application can request switching and simulation operations without being installed on the computer attached to the PXI chassis. The driver on that computer continues communicating with the modules. This separation allows development software, test sequencing and analysis to run away from the instrument rack while the host retains responsibility for hardware access.
Pickering supplies the server software for Windows and Linux, together with Protocol Buffers interface files. These describe the available remote operations and enable client bindings to be generated for environments supporting gRPC, including Python, C#, Go and Java. A test application can therefore use a different language and operating system from the host, with calls following the same published service interface.
gRPC uses HTTP/2 to carry structured requests between client and server. Once a request reaches the gateway, the host driver executes the corresponding operation against a supported Pickering module. Installed chassis and switching cards remain in use as the remote application communicates through the existing instrument controller. It also reduces the need to maintain a separate Pickering driver installation on every engineering workstation.
A shared laboratory rack could remain connected to a device under test while several engineers develop sequences or run permitted operations from other workstations. Automated production validation and distributed development are among Pickering’s intended applications. The separation of software and hardware introduces requirements for access control and scheduling when more than one client might command the same resource, particularly where switching operations affect a powered device.
Compatibility is defined by the Pickering PXI driver’s supported products. Modules can reside in mixed-vendor chassis, but the gateway’s advertised control applies to Pickering hardware covered by that driver. Other manufacturers’ instruments retain their own control interfaces unless separately integrated into the wider test application. Keeping that boundary clear helps avoid assuming that the gateway supplies universal remote operation for every card fitted to a PXI chassis.
Network transport also affects how command sequences are designed. A call initiated on another workstation must cross the network and pass through the gateway before the host driver handles it. Round-trip delay, connection loss and simultaneous requests can influence test orchestration, particularly for production stations with fixed cycle targets. Instrument timing and hardware-triggered operations therefore need to be assessed separately from the latency of the remote software interface.
Pickering describes the gateway as suitable for use with distributed test pipelines and applications running in cloud-hosted environments. Connecting such software to switching hardware creates an additional service endpoint whose network exposure, authentication and permissions must be managed within the deployment. The company’s public release provides the architecture and supported languages; detailed implementation choices belong to the installed server and its operating environment.
Generated client bindings must correspond to the interface definitions supported by the deployed gateway and host driver. Keeping those versions aligned is part of maintaining a remote test system as instrument software evolves. Sequencing may also need to minimise unnecessary back-and-forth requests, leaving time-sensitive physical switching under the most suitable local or hardware control method. These practical choices follow from moving the application away from the instruments while retaining their existing device drivers.
The Remote Gateway server, Protocol Buffers files and user manual are available through Pickering’s download site. Existing supported PXI hardware can therefore be used to evaluate the remote architecture before changing a production test installation. Latency and network behaviour can be evaluated against the intended workload and network configuration before the gateway is deployed in a cycle constrained test station.
