OPC UA File Transfer concepts

Introduction

The OPC UA File Transfer is a set of functionality in OPC UA, built on top of core OPC UA, which defines operation on files and directories residing in the OPC UA server that supports it, similar to file system functionality in operating systems. The OPC UA files and directories can be just a temporarily or persistent storage for arbitrary data, with no added intrinsic semantics, but in many cases they will have a specific meaning defined by the OPC server. For example, files with a predefined name and location can be used to upload a new firmware to the PLC. Files provided by the OPC UA server can also be "virtual", i.e. they do not have to be physically stored inside the server, and the file transfer mechanism can be used to facilitate access to large bodies data that would otherwise be impossible to read or write in a single call (files can be read from or written to in pieces). Some OPC UA "higher-level" specifications use the File Transfer mechanism as well. For example, files are used in Certificate Management to transfer application certificates in their binary form.

Note: The "file transfer" in the name corresponds to how the related OPC UA specification part is titled. In reality, the functionality covers more than just file transfer - it can represent a file system in OPC UA, and provides file access and manipulation operations.

Two basic types of objects are defined in OPC UA File Transfer:

• files
• directories

Files and directories are represented as nodes in the OPC UA address space, in the same way as any other type of object. A file contains data that can be accessed. A directory is a collection of files and directories. If you start with a directory, files and directories can be seen as organized in a hierarchical structure (tree).

The OPC UA server can contain multiple such hierarchical structures; there is no "one and only root" of a file system in OPC UA. In general, a file or directory node can be located anywhere in OPC server's address space, and there can be more of them. A file node can also be completely standalone - be not part of any directory.

In addition, any OPC UA node can aggregate a file system, and there is a predefined way for doing so in the OPC UA specification. The server can do this extending the node by adding a HasComponent reference to a directory object (for the root), with the browse name FileSystem.

Identifying information

Since OPC UA files and directories are represented by nodes in OPC server address space, they can always be identified as such: Directly with their node Ids, or indirectly using OPC UA browse paths. Node Ids are unique in the scope of the OPC UA server. Each node also has its browse name, which corresponds to file or directory name, but the browse name, by itself, cannot uniquely identify any node.

Identification of OPC UA file transfer objects using the node Ids or browse paths is not, however, always practical. There is no prescribed relation between node Ids, and therefore no way to derive, for example, a node Id of a file given by its name from the node Id of its parent directory.

When the files are organized in an OPC UA directory structure, it is convenient to identify in a way that resembles the traditional file systems: Specify a starting directory, and a path to the file or directory from there (a sequence of names). Software based on QuickOPC provides this possibility using a concept that we call named node path. An OPC UA named node path is somewhat similar to OPC UA browse path, but with several important differences:

• The names of the elements on the path are not browse names (qualified names), but simple strings. As such, they do not contain the namespace index or URI. The namespace is implied by the context; in most cases (such as when the node path is used for navigation inside OPC UA file system), the target namespace does not matter at all.
• The types of references that lead from one node on the path to another are not specified in the object (in browse path, the type of reference, together with parameters selecting how the reference should be matched, are specified in each browse path element). The accepted types of references are implied by the context. For example, when the named node path is used for navigation inside OPC UA file system, implied is a forward reference of type Organizes, or its subtype.
• The base (starting) node of the path is given by a node descriptor, and not node Id (the node descriptor specified a node Id, a browse path, or both).
• It is simpler.

Operations

Typical operations on files and directories are all available in OPC UA. Attribute services (reading, writing) or subscriptions are used to access file properties, such as its name, length, or a flag indicating whether the file is writable. Browse services can be used to enumerate contents of directories, or find parent nodes, etc. Operations that are specific to OPC UA File Transfer are then done by calling methods on file and directory objects.