The address space is the core of an OPC UA server and is a representative model of the data the server exposes. The collection of objects and related information that an OPC UA server makes available to an OPC UA client is referred to as its address space. The address space defines the internal node and folder hierarchical structure, the access-rights for each node, how the data for each node will be provided, and display names for each node. An OPC UA server exchanges data in a standardized way with OPC UA clients via an address space model.

See Maintaining the CygNet OPC UA Address Space for more information about generating the CygNet address space, and keeping the address space current with CygNet data.

Once generated the address space can be viewed and navigated in the OPC UA client.

The OPC UA client subscribes to CygNetAlarmType events in order to access alarms on CygNet points. The client can subscribe to events on the OPC UA "Server" object to receive notification of alarms on all points in the CygNet system (the "Server" object is a node which exists on all OPC UA servers). Alternatively, the OPC UA client can subscribe to any level of the address space to receive alarm notifications for all points located within the hierarchy under that node. For example, a client could subscribe to a Facility node to receive alarms for all points on that Facility. Or they could subscribe to an individual RealtimeRecord in the system to receive notification of alarms on that point.

Alarm acknowledgment is the only action supported by the OPC UA Server.

The CygNetAlarmType is one of the CygNet event types defined in the OPC UA server. The RealtimeRecordType is one of the CygNet data types defined in the OPC UA server. Both are described below.

See CygNetAlarmType for more information about how alarms are handled by the OPC UA server.

A custom node specified in the address space that contains the CygNet Current Value Services. Found under Objects in the address space hierarchy. For each CygNet Service type you can drill down to the FacilityTypeSet to each specific facility to see facility attributes, point set, point configuration, and real time record, etc.

CygNet OPC UA Server has defined the following extended (custom) data types to represent the CygNet CVS, facility, point, and real-time records:

• CvsType — contains the CygNet Current Value Services
• FacilityType — contains CygNet facility attributes
• PointConfigurationType — contains CygNet point configuration record properties
• RealtimeRecordType — contains CygNet real-time record (current value) properties

CvsType, FacilityType, PointConfigurationType, and RealtimeRecordType are custom DataTypes found under the Types > ObjectTypes > BaseObjectType in the address space hierarchy. See Extended Data Types and Event Types for more information about each data type properties.

The name to be displayed for each node in the address space, determined by the <DisplayNameProperties> element in the configuration file. There are three types of DisplayNames: Cvs, Facility, and Point. See <DisplayNameProperties> in Configuring the CygNet OPC UA Server for more information.

CygNet OPC UA Server has defined the following extended (custom) event type to represent the CygNet alarm records:

• CygNetAlarmType

CygNetAlarmType is a custom EventType found under the Types > EventTypes > BaseEventType > ConditionType > AcknowledgeableConditionType > AlarmConditionType in the address space hierarchy. See Extended Data Types and Event Types for more information about the CygNetAlarmType properties.

The Local Discovery Server (LDS) is a UA Discovery Server that maintains a list of all OPC UA servers and gateways available on the host where it is running to make its endpoint information available to OPC UA clients with access. The LDS is a service that runs in the background. The CygNet OPC UA Server will periodically connect to an LDS and register itself as being available.

The model builder is a mechanism for generating the address space for the CygNet system, which is run when you first set up the CygNet OPC UA Server, and when you make changes to CygNet that you want exposed in OPC UA (such as adding or removing points or facilities, changes to metadata, etc.). Specifies the XML namespace used by the server.

See Maintaining the CygNet OPC UA Address Space for more information.

The OPC UA specification supports the retrieval of history data entries with the same timestamp, each with distinct values. See Timestamp ordinal below for information about how CygNet handles this type of data.

A node is the basic unit of data in the address space, which provides a standard way for an OPC UA server to represent objects to an OPC UA client. A node is a piece of information (for example, a temperature value) and consists of attributes, the actual data value, and one or more references to other nodes, each in its own address space.

The NodeId uniquely identifies every node in the entire OPC UA address space. For the CygNet OPC UA Server the NodeId is derived from the CygNet tag to ensure uniqueness, allowing the client to make a request to the server to read the Facility node directly. See NodeId Formats for more information about how NodeIds are formatted.

Mapping CygNet Point States to OPC UA Status Codes

The CygNet OPC UA Server can retrieve (via Bridge API) the point status fields and resolved point states for real-time and historical values. The OPC UA server maps CygNet point states to OPC quality and sub-status values in the same way status mappings are handled by the legacy CygNet OPC DA and CygNet OPC HDA servers.

The CvsMetadata provides an external status attribute "ext_status" on the PointStateDefinition element for mapping a point state to a numeric OPC quality and sub-status value. This mapping is used by our legacy OPC DA and OPC HDA servers to communicate the OPC quality and sub-status of a current or historical value.

In order to maintain compatibility between our legacy OPC DA and HDA applications and the OPC UA server application, values assigned to the "ext_status" attribute of a PointStateDefinition node in the CvsMetadata file are translated to the corresponding OPC UA status codes and passed to your OPC UA clients. To be clear, the value assigned to the "ext_status" attribute must still comply with the legacy OPC DA specification for quality and sub-status, but that value will be translated to the corresponding OPC UA status code.

See Mapping CygNet Point States to OPC Quality and Sub-Status for more information about the CygNet point state mappings to the OPC quality and sub-status values.

A profile indicates what specific features of the OPC UA specification are supported. A profile comprises a collection of facets, which describe the specific capabilities supported by the OPC UA server.

CygNet supports history data entries with the same timestamp each with distinct values with ordinals. CygNet assigns each unique timestamp entry an ordinal to allow differentiation between the multiple entries.

OPC UA historical retrieval supports a concept of "modified" values, representing entries with the same timestamp with distinct values. This closely resembles the CygNet concept of "timestamp ordinals".

This release of the CygNet OPC UA Server does not support the retrieval of "modified" historical values. This is because the OPC UA Server talks to CygNet Bridge and the Bridge interface does not provide historical entry timestamp ordinals in the data it returns.

Since the Bridge API does not allow timestamp ordinals to be specified when requesting historical values nor return historical value timestamp ordinals, the underlying value iteration logic in the Bridge API has been modified to skip to the last ordinalized value entry to avoid a possible endless loop of historical value requests and responses.

The transport channel is the secure communication medium used to exchange serialized OPC UA messages between a server and a client over a network. OPC UA supports the sharing of data via many different transport layers using IP-based protocols, such as SOAP/HTTP, HTTPS, and UA TCP.