Skip to content

Chaining and Reverse Connect

Nodes and chains

A Flowgate node is one application. There is no separate edge product and server product: the same software runs everywhere, and configuration decides what each node does.

Any installation can take any place in a chain. A node forwards because it has a parent or an uplink. A node receives because other nodes connect to it or because it holds receivers. One node can do both. "Relay" and "Tier 1" are names for common patterns, not settings: a relay is a node near the plant floor that forwards, and a Tier 1 node is one near the business network that receives.

Nodes link into a chain, which can be any depth. A node in the middle is a parent to the nodes below it and a child to the node above it. A node can also link upward to more than one parent at once, in which case each parent is live and independent.

Data flows up the chain. Configuration and data requests flow down it.

Which side dials

Every node-to-node link uses OPC-UA Reverse Connect by default. On such a link:

  • The child node (nearer OT) opens the TCP connection, outbound, to the parent.
  • The parent node (nearer IT) listens for that connection and does not dial anything.

This is the reverse of the usual OPC-UA arrangement. In Reverse Connect the OPC-UA server starts the socket and the OPC-UA client waits for it. The child is the server that holds the data; the parent is the client that consumes it.

Two ports carry the defaults. Both are configurable.

Port What listens on it Who connects to it
17071 The parent's reverse-connect listener The child node, dialing out
17070 A node's ordinary inbound OPC-UA endpoint Regular OPC-UA clients, when enabled

Port 17070 is optional on a node that only pushes data upward. Turn it on where you want that node to be browsed by a normal OPC-UA client.

Why the OT network needs no inbound firewall rule

The child never accepts a connection from the parent. It only makes one. A firewall between the OT network and the DMZ or business network therefore needs an outbound rule from the child to the parent's port 17071, and no inbound rule at all. This holds at every hop, so a three-node chain crosses two boundaries the same way.

If reverse connect is not acceptable on a particular link, the parent can dial the child instead. In the New Connection wizard the question reads How is the connection established? and the two answers are Reverse Connect and Direct Connect. Direct Connect makes the parent open the socket, which does require an inbound rule at the child. The wizard says so: "This node dials out to the other end's endpoint. Use this only when the other end cannot dial in." The choice is per link, so one chain can mix both.

A link is configured from both ends, on the Connections page.

Add a Federation Uplink. Select Add Reverse Connect Uplink, give the uplink an id, and set Parent URL to the parent's reverse-connect client endpoint, for example opc.tcp://parent.example.com:17071.

Optionally set Push authentication and credentials if the parent requires a named user. Changes take effect immediately: "The node re-dials the new parent immediately (no restart)."

Add a connection whose direction is Reverse Connect, with the child as its target. This creates the mount that the child's subtree appears under, and it is where the link's security policy, security mode and user authentication are set.

The child does not choose these. It reports what it accepted, read-only, once the link is up.

Both ends also need to trust each other's certificate.

Each node has its own X.509 application certificate. When a node first dials in, its certificate is rejected until an operator approves it on Certificate Management. Use Export certificate on the Connections page to download a node's server certificate if you would rather load it in advance.

Trusting is not the same as designating

Approving a certificate trusts it for data access only. To let the peer act as a Flowgate node in the chain, including remote configuration, you must also promote it with Promote to Flowgate Node. Do this only for another Flowgate node, never for a generic OPC-UA client. Confirm the certificate really belongs to the node you think it does before you promote it.

By default the channel itself is encrypted and mutually authenticated: security policy Basic256Sha256 and security mode SignAndEncrypt, with both sides presenting and validating certificates. The user identity presented on the link is a second, separate setting (anonymous, username or certificate); it decides who is logged in, not how the channel is protected.

A node that refuses anonymous access, which is the default for a new installation since 0.44.0, can be mounted only by a parent that signs in with a username or with a certificate bound to a user on that node.

Once the link is up, the uplink reports connected, connecting or disconnected, and the parent's mount reports connected or disconnected. A dropped link redials on its own.

A separate feature with a similar name

A node can also reverse-connect out to an ordinary OPC-UA client, such as a SCADA system or any OPC UA compliant client with the reverse-connect feature sitting behind its own firewall, so that client needs no inbound rule either. That is not chaining. Those targets are not Flowgate parents and get none of the chain's federation or configuration abilities.

What a client sees

A node's embedded OPC-UA server presents its own tags plus the tags of every node below it. Aggregation is transitive, so the node at the top of a chain presents everything, and a node halfway down presents itself and its own subtree.

A client therefore sees the subtree rooted at whatever node it connects to. It does not see nodes above that one.

Containment is structural, not a security control

A node never receives its parent's data simply because data only flows upward. That is a consequence of the topology, not an enforced barrier. Do not rely on chain position to keep one site's data away from another site's operators. Use Data Views for that.

Each child subtree is mounted under its own folder on the parent, under a browse name you choose, so tags from different branches cannot collide. Each namespace a child brings up is given its own entry on the parent, labeled with the source node's name so you can see where it came from. Those labels accumulate as data crosses more hops.

Resolve NodeIds by browsing

A namespace index is assigned by each node, per mount. The same namespace does not necessarily carry the same index on the parent as it did on the child. Clients should resolve NodeIds by browsing or by namespace URI, not by hardcoding a numeric index.

Collection starts on demand

The structure can always be browsed. Seeing that a tag exists does not mean anything is being collected for it.

Value collection starts when a consumer asks for it. A subscription created on a parent propagates down the chain to the node that owns the tag, which then opens the real subscription against the device. When the last consumer goes away, the demand is released down the chain again.

Several consumers of the same tag share one downstream subscription. The first consumer's sampling settings apply to the shared item; a later consumer asking for a faster rate speeds it up, and one asking for a slower rate leaves it alone.

What does travel up the chain regardless is each tag's current state: its last value, quality and timestamp. That is what lets a parent's address space be browsed, and its cost scales with how many tags exist rather than with how fast they change.

OPC-UA only

Demand-driven collection is an OPC-UA behavior. MQTT and SparkplugB are publish-driven, so what a node publishes over them is configured explicitly instead.