Overview: Two Different Things Called "Nodes"
Questions about "how many nodes" an OPC UA system supports almost always collapse two unrelated limits into one word. Before you size anything, split the term:
| Term | What it counts | Who imposes the limit |
|---|---|---|
| Address space node | An entry in the server's information model — Variable, Object, Method, ObjectType, ReferenceType, etc. Each has a NodeId, BrowseName, and references to other nodes. | Server implementation (memory, tag database size, licensing) |
| Connection node / session | A client connection context: a secure channel plus the Session established on it. Frequently called a "connection node" or "channel/session" in vendor documentation. | Server implementation, often licensed or hard-coded |
| Monitored item | A subscribed Variable node inside a Subscription owned by a Session. | Server implementation, per-session and per-server caps |
A server can expose tens of thousands of address space nodes and still refuse your fourth client connection, because those are independent budgets. Diagnose the correct one before you change anything.
Typical Server Capacity Ranges
Capacity spans several orders of magnitude depending on where the server runs.
| Server class | Typical connection-node behavior | Practical implication |
|---|---|---|
| Nano/embedded UA server built into a controller or gateway | Session counts limited to as few as 2 or 3 concurrent connection nodes | One SCADA client plus one engineering/browse tool may already exhaust the server. A third client fails at ActivateSession. |
| Software UA server on a PC (for example KEPServerEX) | Limits connection nodes to 128 | Ample for plant-floor aggregation; the practical bottleneck moves to monitored items and update rates. |
| Aggregating/enterprise server | Vendor-documented; typically bounded by CPU, RAM, and licensing tier | Verify against the vendor datasheet, not against assumptions. |
Embedded servers are the ones that bite. A device that advertises "OPC UA server built in" may implement only the Nano or Micro embedded profile, and the session budget is correspondingly small. Treat the session count as a hard, non-negotiable design input on those devices.
Reading the Server's Actual Session Count at Runtime
If the server implements the standard diagnostics, you can read live session usage instead of guessing. The relevant Variable is:
BrowsePath: Server → ServerDiagnostics → ServerDiagnosticsSummary → CurrentSessionCount
Symbolic name: ServerType_ServerDiagnostics_ServerDiagnosticsSummary_CurrentSessionCount
NodeId: ns=0;i=3097
Namespace: 0 (OPC UA standard namespace)Namespace 0 is reserved for the OPC Foundation's standard nodes, so i=3097 resolves identically on every conforming server that exposes it. That is what makes it a portable health check — you can hard-code it in a diagnostic client without vendor-specific browsing.
Procedure to verify session headroom
- Connect a UA client to the server endpoint with the security policy the production clients will use.
- Browse to
Objects → Server → ServerDiagnostics → ServerDiagnosticsSummary. If the folder is absent or shows BadNodeIdUnknown, the server does not implement the diagnostics node set — fall back to vendor documentation. - Read
ns=0;i=3097(CurrentSessionCount). Record the baseline with all production clients connected. - Check whether server diagnostics are enabled. Many servers ship with the diagnostics object present but the values frozen at zero until a diagnostics-enable flag is set. A constant 0 with clients demonstrably connected indicates diagnostics collection is off, not that there are no sessions.
- Compare the reading against the vendor's documented maximum. Headroom = documented max − CurrentSessionCount.
- Add a monitored item on
i=3097in your SCADA/historian so a session leak trends visibly instead of failing silently at 03:00.
Client-Side Sizing: The Client Chooses How Much to Consume
Clients are not constrained by the server's address space size — they browse and subscribe to only what they need. A client facing a 50,000-node server may legitimately create one session with 40 monitored items. So the question "how many nodes should a client handle?" has no fixed answer either; it is a design decision driven by the following:
| Client design parameter | Effect on server load | Sizing guidance |
|---|---|---|
| Number of sessions opened | Consumes the server's connection-node budget directly | Use one session per application, not one per screen or per thread. Multiplexing many subscriptions onto a single session is the single most effective way to stay inside a 2–3 session embedded limit. |
| Subscriptions per session | Each subscription has its own publishing interval and keep-alive timers | Group items by required update rate; one subscription per distinct rate class. |
| Monitored items per subscription | Dominates CPU and network load | Subscribe only to nodes actually displayed or logged. Do not mirror the entire address space. |
| Sampling interval vs publishing interval | Sampling faster than the data changes wastes server CPU | Set sampling no faster than the underlying device scan; let the server queue and batch into the publish response. |
| Browse depth on connect | A full recursive browse of a large address space is expensive and repeated on every reconnect | Cache NodeIds after first browse; reconnect by NodeId, not by re-browsing. |
| Session timeout | Abandoned sessions occupy connection nodes until timeout expires | Keep the requested session timeout short enough that a crashed client releases its slot promptly, but longer than the worst-case network outage you intend to survive. |
Failure Modes and Diagnosis
| Symptom | Likely cause | Action |
|---|---|---|
| New client cannot connect while existing clients work normally | Connection-node/session limit reached — classic on embedded servers capped at 2 or 3 | Read i=3097; consolidate clients onto fewer sessions or insert an aggregating server between the device and the clients. |
| CurrentSessionCount climbs and never falls | Session leak: clients reconnecting without closing, or session timeout set very long | Ensure clients call CloseSession on shutdown; reduce the requested session timeout so orphans are reclaimed. |
| Connections succeed after a delay following a client restart | Previous session still held until timeout expiry | Same as above — shorten timeout or implement proper session cleanup. |
| Diagnostics node reads BadNodeIdUnknown | Server omits the ServerDiagnostics node set (common in minimal embedded profiles) | Fall back to the vendor's documented limits and to connection-attempt testing. |
| CurrentSessionCount always 0 with active clients | Diagnostics collection disabled in server configuration | Enable the server's diagnostics option, then re-read. |
Design Checklist Before Commissioning
- Obtain the documented maximum session/connection-node count for every UA server in the architecture. A conforming server vendor should publish this; if it is not in the datasheet, request it in writing.
- Count every client that will connect — SCADA, historian, MES, OEE, engineering tools, and the commissioning laptop. Commissioning tools are the most common cause of an unexpected connection refusal on a device limited to 2 or 3 sessions.
- Where the client count exceeds the device limit, place an aggregating server in front of the device: the device sees one session, and the aggregator absorbs the client fan-out.
- Instrument
ns=0;i=3097as a live tag and alarm at a threshold below the documented maximum so you get warning before the next client is refused. - Validate the address space size separately: browse the full model once and record the node count against any licensed tag limits.
- Verify diagnostics access rights and security policy under the same credentials production clients will use, not under an anonymous engineering session.
FAQ
How many nodes can an OPC UA server support?
There is no specification-defined number — it is entirely server-specific. Embedded nano servers may limit connection nodes to 2 or 3, while a PC-based server such as KEPServerEX limits connection nodes to 128. All UA servers should document their supported node counts.
What NodeId reports the current number of OPC UA sessions?
Read ns=0;i=3097, the CurrentSessionCount variable under Server → ServerDiagnostics → ServerDiagnosticsSummary. It resides in namespace 0, so the NodeId is identical on every server that implements the diagnostics node set.
Why does my third OPC UA client fail to connect to a PLC?
Embedded UA servers in controllers frequently cap concurrent connection nodes at 2 or 3. Read CurrentSessionCount to confirm the cap is reached, then consolidate clients onto a single session or place an aggregating server between the controller and the clients.
Is the address space node count the same as the session limit?
No. Address space nodes are entries in the information model (Variables, Objects, Methods); connection nodes are client sessions. A server can expose tens of thousands of address space nodes while allowing only a handful of simultaneous sessions.
How many nodes should an OPC UA client subscribe to?
Only the nodes it actually displays, logs, or controls. The client, not the server, decides its consumption — group items into subscriptions by required update rate and multiplex them onto one session to conserve the server's connection-node budget.
CurrentSessionCount reads zero even though clients are connected — why?
Most servers ship with diagnostics collection disabled; the node exists but the value stays frozen at 0. Enable the server's diagnostics option in its configuration, then re-read i=3097.
