OPC UA overview
===============

OPC UA can look overwhelming because it is more than a wire protocol. The most
important idea is that OPC UA describes an information model and then provides
services for accessing that model.


The address space
-----------------

The center of OPC UA is the address space. It is a graph of nodes that describe
devices, variables, methods, data types, and relationships. A client normally
does not start by knowing every value path in advance. It can browse the address
space, discover what the server exposes, and then read, write, or call methods
on specific nodes.

Important node concepts:

**Node**
  One item in the address space, such as an object, variable, method, data type,
  or reference type.

**NodeId**
  Stable identifier used by services such as Browse, Read, Write, and Call.

**BrowseName**
  Name used while browsing from one node to another.

**Reference**
  Relationship between nodes, such as ``HasComponent`` or ``HasProperty``.

**Namespace**
  A URI-indexed naming scope that prevents models from different vendors or
  companion specifications from colliding.


Types and instances
-------------------

OPC UA has an object-oriented type system. A model can define reusable types
and then instantiate objects from those types.

.. list-table::
  :header-rows: 1
  :widths: 25 75

  * - Type
    - Purpose
  * - ObjectType
    - Template for objects. It can define child variables, methods, and
      structure.
  * - VariableType
    - Template for variables and structured variable layouts.
  * - DataType
    - Type definition for scalar values, structures, and enumerations.
  * - Structure
    - Ordered set of named fields.
  * - Enumeration
    - Named integer values.
  * - Method
    - Callable operation exposed by an object.

This is why OPC UA is useful in industrial systems: a value can carry context.
The server can describe what the value means, where it belongs, what type it
has, and what operations are available.


Common Client/Server services
-----------------------------

The Client/Server model uses request/response services.

.. list-table::
  :header-rows: 1
  :widths: 30 70

  * - Service
    - Purpose
  * - FindServers
    - Discover servers known to a discovery endpoint.
  * - GetEndpoints
    - Discover endpoint URLs, security modes, and user token policies.
  * - OpenSecureChannel
    - Establish the secure transport channel.
  * - CreateSession
    - Create a logical client session.
  * - ActivateSession
    - Authenticate the user for the session.
  * - Browse
    - Discover nodes and references in the address space.
  * - Read
    - Read node attributes, commonly variable values.
  * - Write
    - Write node attributes.
  * - AddNodes
    - Add nodes to the address space.
  * - Call
    - Invoke a method node.


Why it feels complex
--------------------

OPC UA has several layers that interact:

* The information model describes the address space.
* The service model defines operations such as Browse and Read.
* The security model defines certificates, policies, users, and sessions.
* The encoding layer defines binary, JSON, XML, and PubSub message formats.
* Companion specifications define vendor-neutral models for industries and
  device types.

Most application code only needs a subset of this. A simple server may create
objects and variables, set callbacks for values, and support anonymous access.
A more complete server may load NodeSet2 XML files, expose methods, configure
security policies, and validate user tokens.


Practical mental model
----------------------

Use this sequence when learning the stack:

1. Start with the address space: objects, variables, methods, and NodeIds.
2. Learn Browse, Read, and Write.
3. Add sessions and authentication.
4. Add custom types only when your data needs structure and semantics.
5. Use PubSub over MQTT when you need message distribution rather than a
   browseable address space.