TSN vs Standard Industrial Ethernet: A Qbv Guide
Read more...
OPC UA, or OPC Unified Architecture, is a platform-independent standard for exchanging information between systems and devices. Its central idea is simple: a server exposes information in a structured AddressSpace, and clients use defined services to find, read, change, or monitor that information.
The standard covers more than message transport. It defines an information model, a message model, a communication model, and a conformance model. Together, those models give applications a shared way to represent information and interact across different systems (OPC Foundation, OPC UA Part 1).
TL;DR: OPC UA organizes server information as nodes and references in an AddressSpace. Clients interact with that AddressSpace through standard services and can maintain sessions and subscriptions. Common types, services, and conformance profiles support interoperability, but implementations may expose different capability subsets.

OPC UA defines a common infrastructure for information exchange. Part 1 describes four parts of that infrastructure: an information model for structure and meaning, a message model for application interactions, a communication model for moving data between endpoints, and a conformance model for interoperability.
This layered design separates the core architecture from particular computing platforms and network transports. OPC UA can therefore expose a consistent AddressSpace and service model while allowing mappings and encodings to be specified separately. Part 1 names text, binary, and JSON encodings, along with several underlying transports, but leaves their detailed definitions to other parts of the series.
That boundary matters. Part 1 is an overview of the architecture, not an implementation guide. It explains the roles of clients, servers, services, sessions, nodes, references, types, and profiles. Detailed service definitions, protocol mappings, security rules, and information-model definitions live in other parts of OPC 10000.
In the client-server model, an OPC UA client calls services that an OPC UA server exposes. The client sends a service request; the server performs the operation and returns a response. A client may interact with multiple servers, and a server may interact with multiple clients.
The services cover distinct parts of the interaction. Discovery services help a client find servers and connection information. Session services establish an application-layer connection for a user. Attribute, method, and view services let a client work with information exposed by the server. Monitored-item and subscription services let the server return notifications about changes and events.
A session holds state across requests. Part 1 lists subscriptions, user credentials, and continuation points as examples of session state. The session is a logical connection rather than the underlying transport itself, so the client-server interaction is not reduced to a single request on a socket.
Subscriptions change how a client receives updates. The client creates monitored items for variables, attributes, or event notifiers. When a monitored condition occurs, the server creates a notification and returns it through a subscription. This is part of the defined client-server service model, not a vendor-specific polling convention.
The AddressSpace is the collection of information a server makes visible to clients. OPC UA represents its contents as nodes connected by references. A reference is an explicit, named relationship from one node to another, so the model can express more than a flat list of tags.
Nodes represent real objects, their definitions, and their relationships. An Object node can represent a physical or abstract part of a system. A Variable node contains a value. A Method is a callable function associated with an object. Attributes hold primitive characteristics of nodes, including the values of variables.
References let a server arrange nodes into hierarchies or a more interconnected network. The top levels of the AddressSpace follow a common structure, while a server can organize its own nodes for the system it represents. A server may also expose a View, which is a subset of the AddressSpace intended to simplify client access.
This structure makes browsing possible. A client can use services to inspect the nodes and references a server exposes instead of relying only on a separately agreed list of names. Browsing does not mean every client understands every domain model automatically, but it gives the client a standard way to discover the available structure.
OPC UA information models use nodes, references, types, and data-type definitions to describe a system. A server can expose type definitions for objects and their components. Those definitions may be common, system-specific, defined by a standards organization, defined by a vendor, or defined by an end user.
The type system gives a client more context than a value alone. Part 1 states that clients can query metadata describing data formats and, in many cases, determine an unfamiliar format at runtime. It does not promise that every client can interpret every model without prior domain knowledge.
Part 1 uses a temperature transmitter as an example of the integrated object model. A server can represent the transmitter as an object composed of a temperature value, alarm parameters, and alarm limits. The point is the relationship between those elements: the object groups data and related behavior within one model.
Industry groups can define how their information models are represented in a server AddressSpace. This provides shared modeling building blocks without requiring every server to expose the same domain-specific objects.
OPC UA supports interoperability through common models, services, and conformance profiles. The common AddressSpace and service model establish how clients inspect information and request operations. Type definitions and references establish how servers describe the information they expose.
Profiles address differences in implementation scope. OPC UA defines a broad set of capabilities, but a server may implement only a subset. A profile groups capabilities for conformance, and a client can discover the profiles a server claims and tailor its interactions accordingly.
This is a more precise claim than saying that any OPC UA product works with every other product without configuration. The architecture supplies shared rules and discoverable capabilities. Actual interoperability still depends on the profiles, information models, transports, and encodings supported by the applications involved.

Part 1 also places security inside the overall architecture. It describes authentication, confidentiality, integrity, secure channels, and configurable security profiles at a high level. It does not establish that every mechanism is always required or enabled; installation designers select and configure measures for the needs of their system. Detailed security requirements belong to the security part of the specification.
Part 1 is a conceptual foundation. It does not provide performance benchmarks, latency figures, adoption rates, market forecasts, project costs, or vendor comparisons. It also does not prescribe one deployment pattern for every plant.
Use it to understand the architecture and vocabulary. For detailed AddressSpace rules, services, mappings, profiles, or security behavior, follow the corresponding part of the OPC 10000 series identified in Part 1. For a separate discussion of messaging choices, see OPC UA vs MQTT.
OPC Unified Architecture is a platform-independent standard for exchanging information between systems and devices. It defines information, message, communication, and conformance models rather than tying the architecture to one platform or one representation of industrial data.
An AddressSpace is the collection of information an OPC UA server makes visible to clients. It represents that information as nodes connected by references. Attributes describe primitive characteristics of nodes, while object and variable types give the modeled information a defined structure and meaning.
A client calls services exposed by a server. Those services let the client send requests and receive responses, browse or access the AddressSpace, and create subscriptions for notifications. A session keeps state such as subscriptions and user credentials across multiple requests.
No. OPC UA provides common models, services, and conformance profiles that promote interoperability. Servers may implement different subsets of the available capabilities, so a client can discover a server’s profiles and adapt its interactions to the functions that server supports.
OPC UA gives clients and servers a shared architecture for exchanging modeled information. The server exposes an AddressSpace of nodes and references; clients use services, sessions, and subscriptions to interact with it. Types and profiles make capabilities discoverable and support interoperability without promising that every implementation exposes the same functions.
The useful next step depends on the question you need to answer. Read the relevant OPC 10000 part for implementation detail, or use the IIoT protocol comparison to place OPC UA beside other industrial communication approaches.
Read more...