In Your OT Environment¶
The Double Agent Connector is built for the boundary between an operational technology (OT) network and the people who analyze its data in Seeq. This page is for whoever is responsible for that boundary: what the connector changes, what crosses, in which direction, and who stays in control.
Where it sits¶
- Inside the Seeq Agent, on a host in the protected network, where your Seeq Agent already runs. The connector does not run on the Seeq server.
- On the agent's existing connection. The Seeq Agent connects out to your Seeq server; requests and results travel over that connection. Nothing new listens on the agent's host, and no inbound firewall rule is added.
- Beside its plugins. The work is done by plugins in a folder on the same host. They are installed there by whoever administers that host.
What crosses the boundary¶
| Direction | What | Notes |
|---|---|---|
| Seeq → agent | A request: which Seeq item, which action, the action's parameters | Written by whoever created the request in Seeq; treated as untrusted input |
| Agent ← Seeq | Reads of what the request names (an item's properties, a signal's samples) | Through the agent's own Seeq session, as the agent's identity |
| Agent → Seeq | The result, as samples; the signal's place in an asset tree | Shown in Seeq like any other signal |
What a plugin does on the agent's side, and what it may reach in that environment, is decided when the plugin is built and installed, not by the request.
Who decides what runs¶
- Only installed plugins run. A request selects an action by name from the plugins installed on that agent; it cannot supply code, commands or queries. Adding or removing a plugin is a change on the agent's host, made with the agent stopped.
- The license caps how many plugins load, and the connector records each plugin it loads, with its name, version, vendor and actions, every time the agent starts.
- Each request has a time limit. A plugin runs inside the agent's process; install only plugins you trust, as you would any software on that host.
- A plugin that uses the Seeq software development kit (SDK) must be built for the connector's Seeq version; the connector refuses one that does not match.
What is designed per deployment¶
Some controls depend on your environment and are agreed with you rather than fixed in the product today:
- Which items a connection may serve. Today any signal created on the connector's datasource can make a request.
- Who asked. Seeq does not tell a connector who is viewing a signal, so the requester named in a request is recorded as an unverified claim. Verifying the requester is designed with you.
- How requests are started. Today from a Seeq Data Lab notebook; a form in Seeq Workbench, as a Seeq add-on, is planned for end users.
What it means operationally¶
- No new system of record. Results are computed on request from what is in Seeq and on the agent's side; the connector keeps no separate store of results.
- Signals people create are left alone. The connector organizes them in an asset tree, but never removes or rewrites them.
- Licensed per host, offline. The license file is bound to the agent's host; no license server is contacted.
- Installed and updated like EEI's other connectors: see Onboarding and Updating a Connector.