Skip to content
Start free evaluation

Services

An OPC UA client talks to a server by calling services. A service is a pair of a request message and a response message. Part 4 defines the services; Part 6 defines how messages are encoded into bytes and carried over opc.tcp.

An opc.tcp connection has three layers:

  1. UA Connection Protocol (UACP): after the TCP connection opens, Hello (HEL) and Acknowledge (ACK) negotiate buffer sizes. Hello carries the endpoint URL the client uses (Part 6, section 7.1).
  2. Secure channel: OpenSecureChannel selects the security policy and mode and derives symmetric keys. From then on every message is signed, or signed and encrypted, with those keys (Part 4, section 5.5, SecureChannel Service Set; Part 6, secure conversation).
  3. Session: CreateSession creates a session and ActivateSession authenticates the user (Part 4, section 5.6, Session Service Set). Once the session is active, you can call other services.
Client Server
| HEL / ACK |
| OpenSecureChannel (SecurityPolicy None) ------> | discovery
| GetEndpoints ----------------------------------> |
| <--------------------- EndpointDescriptions ---- |
| CloseSecureChannel ----------------------------> |
| |
| HEL / ACK |
| OpenSecureChannel (policy, mode, certificate) -> | secure channel
| <------------------- channel token, nonce ------ |
| CreateSession ---------------------------------> | session
| <----------- session id, nonce, certificate ---- |
| ActivateSession (user identity token) ---------> |
| Read / Browse / Call / Publish ... ------------> | services
| <------------------------------------- responses |
| CloseSession ----------------------------------> |
| CloseSecureChannel ----------------------------> |

The first connection is discovery: it fetches the list of endpoints. An endpoint combines a URL, a security policy, a security mode, the server certificate and the user token types it accepts. The client picks one combination from the list and opens the second connection with it.

Service set Main services Part 4
Discovery FindServers, GetEndpoints Section 5.4
SecureChannel OpenSecureChannel, CloseSecureChannel Section 5.5
Session CreateSession, ActivateSession, CloseSession, Cancel Section 5.6
NodeManagement AddNodes, AddReferences, DeleteNodes, DeleteReferences Section 5.7
View Browse, BrowseNext, TranslateBrowsePathsToNodeIds, RegisterNodes Section 5.8
Attribute Read, Write, HistoryRead, HistoryUpdate Section 5.10
Method Call Section 5.11
MonitoredItem CreateMonitoredItems, ModifyMonitoredItems, SetMonitoringMode, SetTriggering, DeleteMonitoredItems Section 5.12
Subscription CreateSubscription, ModifySubscription, SetPublishingMode, Publish, Republish, TransferSubscriptions, DeleteSubscriptions Section 5.13

The services you’ll use most often:

  • Browse lists the references that leave a node. You can filter by direction, reference type and NodeClass. When there are many results, the server returns a continuation point and you fetch the rest with BrowseNext.
  • Read and Write access node attributes. One request can carry many nodes, and each item gets its own result.
  • Call invokes a method on an object with input arguments. The result holds the method’s StatusCode, one result per argument and the output arguments.
  • CreateSubscription, CreateMonitoredItems and Publish deliver changes of values and events as notifications; see Subscriptions and the publish cycle.
  • HistoryRead reads stored history; see Historical access.

opc.tcp uses the UA Binary encoding (Part 6, section 5.2). A service message starts with the encoding NodeId of its type, followed by a RequestHeader or ResponseHeader and the body.

Message Encoding NodeId
ReadRequest / ReadResponse i=631 / i=634
WriteRequest / WriteResponse i=673 / i=676
BrowseRequest / BrowseResponse i=527 / i=530
CallRequest / CallResponse i=712 / i=715
HistoryReadRequest i=664
CreateSubscriptionRequest i=787
CreateMonitoredItemsRequest i=751
PublishRequest i=826
GetEndpointsResponse i=431
ServiceFault i=397

The RequestHeader holds the session’s authentication token, a timestamp, the request handle, the diagnostics mask and a timeout hint. The ResponseHeader echoes the request handle and carries the service result. When the server can’t process the request at all, it answers with a ServiceFault.

The PDComm SDK client handles the connection and its security; your application builds the service messages in UA Binary. Because the SDK doesn’t wrap each service in its own typed API, every service goes through the same functions.

Step C function What it does
Discovery pdcomm_opcua_discover Sends GetEndpoints over a None secure channel and returns the whole GetEndpointsResponse. It doesn’t validate certificates.
Connect pdcomm_opcua_client_connect Fetches the endpoints, picks the one whose policy and mode match exactly, validates the server certificate, then sends OpenSecureChannel and CreateSession. It never falls back to another policy.
Authenticate pdcomm_opcua_client_activate_anonymous, pdcomm_opcua_client_activate_user_name Sends ActivateSession.
Request pdcomm_opcua_client_begin Queues a complete request message. The SDK fills in the authentication token, timestamp and request handle; a zero timeoutHint becomes the connection timeout.
I/O pdcomm_opcua_client_poll Sends and receives bytes on the socket without blocking.
Response pdcomm_opcua_client_take_response Returns the validated response buffer, or PDCOMM_OPCUA_EMPTY while it hasn’t arrived.
Response info pdcomm_opcua_response_get_info Reads the response’s encoding ID (binary_id) and service result (service_status).
Close pdcomm_opcua_client_close Sends CloseSession (deleting subscriptions) and CloseSecureChannel.

pdcomm_opcua_client_begin accepts FindServers, GetEndpoints, Cancel, Browse, BrowseNext, TranslateBrowsePathsToNodeIds, RegisterNodes, UnregisterNodes, Read, Write, Call, HistoryRead, HistoryUpdate, the Subscription and MonitoredItem services, AddNodes, AddReferences, DeleteNodes and DeleteReferences. Secure channel and session requests go only through their own functions.

The return value of a C ABI function describes the call itself; OPC UA StatusCodes stay inside the response body. When a server answers with a ServiceFault, for example, pdcomm_opcua_client_take_response still returns PDCOMM_OPCUA_OK and service_status is Bad.

The SDK creates no threads and calls no callbacks. While a request is outstanding, your application calls pdcomm_opcua_client_poll regularly. One client can have up to 64 outstanding requests.

The C++ header pdcomm_opcua.hpp, the Qt worker and the .NET assembly wrap the same C ABI. You run this flow yourself in the C client tutorial.

pdcomm_opcua_server_create creates a server with a standard address space: the Server object, the namespace array and the standard types. Your application adds variables with pdcomm_opcua_server_add_variable and calls pdcomm_opcua_server_poll regularly. This server handles the Discovery, Session, View, Attribute, Method, Subscription and MonitoredItem services from memory. It has no external data provider, events, history or PubSub, and it accepts anonymous user tokens only.

Discovery and connect need a license for the opcua-client module, and creating a server one for opcua-server. Without it these calls are refused with PDCOMM_OPCUA_LICENSE_REQUIRED before any network I/O; clients and servers that already exist keep working. See Install and check a license.

The PDComm OPC UA simulator wraps services in JSON commands called actions. {"action":"browse","node":"ns=2;s=Simulator"}, for example, builds and sends a BrowseRequest and returns the result as JSON. You also use the simulator for the features the SDK server lacks, such as events, history and PubSub. Headless simulator lists the actions.

Security covers what protects the secure channel and the session.