Common Vision Blox 14.0
OPC UA: Communication Framework for Industry 4.0

Common Vision Blox Tool


 C-Style 

 C++ 

 .Net API (C#, VB, F#) 

 Python 
 CVOpcUa.dll   Cvb::OpcUa      cvb.opcua 

Introduction

This document provides a outline of the ...

  1. OPC UA Standard maintained by the OPC Foundation.
  2. OPC UA APIdeveloped by STEMMER IMAGING.
  3. More Links to help understanding of the Standard as well as the OPC UA API.
  4. The Theory Of Operation when working with the OPC UA API.

And a link for practical oriented people: Tutorials (C++, Python, C#)

Note that:

  • The scope of the OPC UA Standard exceeds the intended scope of this document, i.e. in many cases concepts are only outlined with an external link for further reading.
  • This document contains multiple snippets of C++ code, the class/method/function name are practically identical in Python and C#.

OPC UA Standard

Open Platform Communication (OPC) Unified Architecture (OPC UA) is a data exchange standard for platform independent service oriented architecture (SOA).

The standard is maintained by the OPC Foundation and has the design goals to be:

  • Secure (Authorization & Authentication)
  • Multi-Platform
  • Multi-Domain
  • Multi-Vendor
  • Scalable and interoperable

The Standard itself is split into several parts:

Overview and Concepts
Security Model
Address Space Model
Services
Information Model
Mappings
Profiles
Data Access
Alarms and Conditions
Programs
Historical Access
Discovery and Global Services
Aggregates
PubSub
Device Information Model

OPC UA API

The OPC UA API provided by STEMMER IMAGING is an implementation of the OPC UA Standard.

The API is available in four different flavors:

  • A C API (CVOpcUa.dll)
  • A C++ API (part of CVB++)
  • A Python API (part of CVBpy)
  • A .Net API (part of CVB.net)

Documentation for all APIs can be found here: OPC UA API. We also provide a conceptual explanation as well as some practical examples. As well as coding examples for Python, C# and C++.

Note: It is recommend not to use the C API, in favor of C++, C# or Python. The recommended APIs provide a much higher ease of use for a potential user.

Refer also CVB API overview.

Links

Regarding the OPC UA Standard:

The specification itself is available here (requires registration)
Further Information about the OPC UA Standard can be found at the OPC Foundation
Information about various OPC UA companions specifications (workinggroups)
Information about the OPC Vision companions specification

Regarding the STEMMER IMAGING OPC UA API:

The API itself is available via the Common Vision Blox Installer
Question regarding the API can be asked at ...

Theory of Operation

  • Communication: This chapter explains the concepts and interaction between a server and client.
  • Modeling: This chapter explains the modeling aspect of OPC UA with the STEMMER IMAGING API.
  • Use Cases: A short chapter on how the API will interact with itself and third party applications.
  • And a link for practical oriented people: Tutorials (C++, Python, C#)

Communication

The communication with the API follows the usual Server / Client architecture. Note:

  • The OPC UA Standard also supports a PubSub model for communication, but we do not provide an interface for it.
  • The OPC UA Standard has an entire chapter on it's security model, i.e. encryption etc.. We do not use it.

You may also want to check the Use Cases section to understand how you can use OPC UA with other third party applications.

Server and Client

Server

The Server provides the session, to which any number of clients can connect to.

Like in other Server / Client architecture the server host all the data, whereas the client merely request data from the server. For the creation of the server you simply must name a port. Typically the ports are 4840 and 4843 for OPC UA.

  • 4840 is intended for non-encrypted communication.
  • 4843 is intended for tls/ssl encryption.

However you can use (almost) any port you want. See registered ports of the IANA.

Example in C++:

// create server object
auto server = Cvb::OpcUa::Server::Create(4840);
// start the server
server->Start();
// stop the server.
server->Stop();
static ServerPtr Create(const std::uint16_t port)

Callbacks:

The server-side of the architecture allows the registration of callback objects.

Callback are not available for all NodeClasses. But VariableNodes for example have callbacks for read and write operations on their variable data. MethodNode are an interface to 'call'/'execute' functions on the server from a client.

ATTENTION: In the current version we do not support the security aspect of OPC UA, i.e. communication does not require authorization and is unencrypted.

However if the security model interests you: https://opcfoundation.org/developer-tools/specifications-unified-architecture/part-2-security-model/

Example can be found in the Use Cases and the Tutorials.

Namespaces:

Namespaces are explained in the Node IDs chapter.

Further reading:

Client

The Client connects to a Server using a URL and port.

In general this has the syntax protocol://URL:port, where protocol is always equal to opc.tcp with our API. Example:

"opc.tcp://192.168.0.1:4840" 

or

"opc.tcp://MY_COMPUTER:4840"

Example in C++:

// create and connect client
auto client = Cvb::OpcUa::Client::Create("opc.tcp://127.0.0.1:4840");
static OpcUa::ClientPtr Create(const Cvb::String &Url)

The Client does not have a start/stop mechanism. Instead the connection is established at object construction and disconnected at object deconstruction.

Browse:

Browsing is an important part of the OPC UA Standard, specifically it is part of the service oriented architecture (SOA).

Browsing is a sophisticated search function, with regards to data modeling within the Server. It is based on the Node ID concept. For ease of use, we opted to make browsing a method of any node

Example in C++:

// get root node
auto obj = client->RootNode();
// defining our browsefilter
// apply the browsefilter. The result is a vector of nodeIds.
auto result = obj->Browse(*bf);
static BrowseFilterPtr Create()

Further reading:

Use Cases

The API can be used in several ways. Like mentioned before we have a Server and a Client implementation.

We also provide several coding examples: External Link for Python, C# and C++. These example will also be available in your local installation of CVB.

Server Only:

In this example you are developing a application, for example a vision system, which should expose data and functions to the network.

For example: The system has to expose the frame rate of a camera as well as a 'start' and 'stop' function. The task in this case is to ...

  1. Create a Server (this is done by choosing a port)
  2. Add a VariableNode to the Server, to expose the frame rate (in practice, you will need to register a callback on 'read' of the VariableNode; see OpcUa/ServerClientInteraction.)
  3. Add the MethodNodes 'start' and 'stop'. The execution of the MethodNodes, will cause a callback to be triggered, which allows you to start/stop your system.
  4. (At this point the server is ready.)

The Client application, to connect to the Server, must not be our implementation of the OPC UA Standard, it could be a third party product.

Callback example as intended with the API:

// This is a generic example of registering a callback.
// create server object
auto server = Cvb::OpcUa::Server::Create(4840);
// ... some parameter for node creation are set here.
// create a "float" node in namespace "1"
auto node = Cvb::OpcUa::FloatNode::Create(1, nodeName, ...);
// add the float node.
server->AddNode(*node);
// register a callback to the float node.
auto callbackCookieWrite = node->RegisterReadCallback([&node]()
{
std::wcout << L"write to " << node->DisplayName() << std::endl;
});
static FloatNodePtr Create(std::uint16_t namespaceIndex, const Cvb::String &name, const OpcUa::NodeID &parentNodeID, double value)

Client Only:

In this example we are using the OPC UA Client to connect to a third party devices, which hosts a OPC UA Server.

The third party device exposes a Variable 'ErrorState' (this is the Node ID). And a Method 'MagicallyFixProblems', which should executed if 'ErrorState' signals a problem. The task are ...

  1. Create and Connect to the device (this is done via a URL and port)
  2. Retrieve the Variable 'ErrorState'. This can be done by ...
    • Using the Browse service, if you do not know the Node IDs or ...
    • Using the Node ID, if you already know the Node IDs.
  3. Subscribe to the Variable, this is a callback if the Node changes value.
    • If the value of the Variable changes, but the value does not signal an error, do nothing otherwise ...
    • If the value of the Variable signal an error ...
      • Retrieve the Method 'MagicallyFixProblems'. See 2.b and 2.a.
      • Execute the Method (the functionality of the Method is provided by the device).

Multiple Servers:

It is entirely possible to run multiple Server on any system, however each Server requires it's own port.

Multiple Clients:

OPC UA support having multiple Clients connect to a single Server.

Single Client multiple Server:

In our implementation it is not possible to connect to multiple Servers from a single Client, however you can have multiple instances of Clients running within a single process.

For information on use-cases detach from our API, please read: https://opcfoundation.org/developer-tools/specifications-unified-architecture/part-10-programs/

Modeling

The modeling aspect of OPC UA is a node-based concept.

Each Node has any number references to other nodes and each node is identified by a Node ID.

The above example simple show random nodes without context. OPC UA gives such a model context and therefore allow to model complex and simple systems. Note that all actual modeling is done on the Server-side of our API.

Node IDs

Node IDs are unique identifiers for every node within a OPC UA System. Node IDs will be extensively be used by the Server and Client for accessing, referencing, creating and deleting Nodes. Each Node ID consists of 3 components:

  1. NamespaceIndex
  2. Identifier
  3. DataType

Example of Node IDs:

A Node ID '123' of type integer in namespace 1.

Node ID
NamespaceIndex 1
Identifier 123
DataType Numeric

A Node ID 'HelloWorld!' of type string in namespace 3.

Node ID
NamespaceIndex 3
Identifier 'HelloWorld!'
DataType String

Example with CVB++:

// Creation of a node id "HelloWorld!" in namespace 3 with type 'String' (implicit)
auto hello = Cvb::OpcUa::NodeID::Create(3, "HelloWorld!");
static NodeIDPtr Create(Namespace0NodeID id)

Namespace Index:

Namespaces in context for OPC UA are part of the unique identifier. They are always represented as an integer.

Namespace Index == 0

The namespace index equal to 0 contains many predefined Node IDs. These Node IDs are important access predefined Nodes and NodeTypes.

Example with CVB++:

// create a nodeId of a "folder" type. This is needed to create a folder node.

Identifier:

The identifier must be unique for the namespace. There are several valid data types. See OPC UA API for Implenentation details.

Further Reading:

https://opcfoundation.org/developer-tools/specifications-unified-architecture/part-3-address-space-model/

Nodes

Nodes are the central data model for any OPC UA system. To understand Nodes, it is important to understand the Node ID concept. Each Node has several Attributes and References.

Attributes:

Attributes are essentially just data fields, defined by the OPC UA Standard. Examples are "DisplayName", i.e. a human readable name, and "Node ID", the aforementioned Node ID. For a full list of see the OPC UA API. Or here for the specific values (C++ enum).

Attributes may be optional or mandatory depending on the NodeClass. However this is less import in our API since we will require all mandatory information at object construction.

References:

References connect one Node to another Node, within a specific semantic meaning. All References are predefined Node IDs.

For Example:

A folder Node (i.e. a folder which may contain other Nodes) has the "hasComponent" Reference to all Nodes within. A custom Node may have the "hasTypeDefinition" Reference to another Node.

Another Example in C++:

// create the HasComponent reference between two nodes
node->AddReference(someOtherNode, Cvb::OpcUa::ReferenceType::HasComponent, ...);

NodeClass:

The node class is an important Attribute of any node. There are 8 basic node concepts(1):

  1. Object
  2. Variable
  3. Method
  4. View
  5. ObjectType
  6. VariableType
  7. RefereceType
  8. DataType

Objects can represent anything, they are an interface to model any resource available.

Variables represent any data. For example our implementation has a generic VariableNode, which holds data in string, integer or other form.

Methods provide an interface to call methods/function on the server system. Example: A system has "Start()" and "Stop()" functionality exposed via MethodNodes.

Views restrict and sort the visibility of Nodes. Example: A technician may use the "Debug View", which gives full access on a complex system, while a controller (the job description) may use a simple "Input/Output View".

The Type NodeClasses serve to create new Nodes, this process is similar to classes in object oriented programming. I.e. a VariableType serves as a template to create new Variables.

(1) There is 9th class in our implementation (i.e. BaseNode), simply for inheritance purposes, since all node share a common base.

Further reading:

Tutorials

You can build and run the following tutorial materials to get a further understanding of the topics discussed above:

  • OpcUa/BareboneClient
  • OpcUa/BareboneServer
  • OpcUa/ServerClientInteraction

Each example is available in Python, C# and C++.