IBM Tivoli Netcool/OMNIbus Probe for OPC Unified ... · For probes supported only on Windows operating systems, ... HP-UX Integrity-based systems ... 2 IBM Tivoli Netcool/OMNIbus

Netcool/OMNIbus Probe for OPC Unified Architecture (UA)Version 1.0

Reference GuideNovember 7, 2014

SC27-6552-00

��

Netcool/OMNIbus Probe for OPC Unified Architecture (UA)Version 1.0

Reference GuideNovember 7, 2014

SC27-6552-00

��

NoteBefore using this information and the product it supports, read the information in “Notices and Trademarks,” on page 65.

Edition notice

This edition (SC27-6552-00) applies to version 1.0 of the IBM Tivoli Netcool/OMNIbus Probe for OPC UnifiedArchitecture (UA) and to all subsequent releases and modifications until otherwise indicated in new editions.

© Copyright IBM Corporation 2014.US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contractwith IBM Corp.

Contents

About this guide . . . . . . . . . . . vDocument control page . . . . . . . . . . . vConventions used in this guide . . . . . . . . v

Chapter 1. IBM Tivoli Netcool/OMNIbusProbe for OPC Unified Architecture (UA) 1Summary . . . . . . . . . . . . . . . 2Getting started. . . . . . . . . . . . . . 3Installing probes . . . . . . . . . . . . . 4Configuring the probe . . . . . . . . . . . 5Data acquisition . . . . . . . . . . . . . 7

ObjectServer information . . . . . . . . . 7OPC UA communications information . . . . . 8Connecting to the OPC UA server . . . . . . 9Establishing a secure connection to the OPC UAserver . . . . . . . . . . . . . . . 11Notification retrieval and synchronization . . . 15Reconnection and probe backoff strategy . . . 17Inactivity . . . . . . . . . . . . . . 18Data stream capture . . . . . . . . . . 18Support for Unicode and non-Unicode characters 19Peer-to-peer failover functionality . . . . . . 19Using the OPC Foundation sample server . . . 20

Running the probe . . . . . . . . . . . . 22Running multiple probes . . . . . . . . . 22

Running the probe as a Windows service . . . 23Properties and command line options . . . . . 24Elements . . . . . . . . . . . . . . . 32Error messages . . . . . . . . . . . . . 33ProbeWatch messages . . . . . . . . . . . 42

Chapter 2. The XML configuration filesfor event and data change notifications 45Structure of the XML configuration files . . . . . 46<ListOfMonitoredItemCreateRequest> . . . . . 47<MonitoredItemCreateRequest> . . . . . . . 47

<ItemToMonitor> . . . . . . . . . . . 48<RequestedParameters> . . . . . . . . . 48<Filter>. . . . . . . . . . . . . . . 49

<DataChangeFilter> . . . . . . . . . . . 49<EventFilter> . . . . . . . . . . . . . . 50

<SimpleAttributeOperand> . . . . . . . . 51<ContentFilterElement> . . . . . . . . . 51

Customizing the XML configuration files . . . . 52

Appendix. Notices and Trademarks . . 65Notices . . . . . . . . . . . . . . . . 65Trademarks . . . . . . . . . . . . . . 67

© Copyright IBM Corp. 2014 iii

iv IBM Tivoli Netcool/OMNIbus Probe for OPC Unified Architecture (UA): Reference Guide

About this guide

The following sections contain important information about using this guide.

Document control pageUse this information to track changes between versions of this guide.

The IBM Tivoli Netcool/OMNIbus Probe for OPC Unified Architecture (UA)documentation is provided in softcopy format only. To obtain the most recentversion, visit the IBM® Tivoli® Knowledge Center:

http://www-01.ibm.com/support/knowledgecenter/?lang=en#!/SSSHTQ/omnibus/probes/common/Probes.html

Table 1. Document modification history

Documentversion

Publicationdate

Comments

SC27-6552-00 November 7,2014

First IBM publication.

Conventions used in this guideAll probe guides use standard conventions for operating system-dependentenvironment variables and directory paths.

Operating system-dependent variables and paths

All probe guides use standard conventions for specifying environment variablesand describing directory paths, depending on what operating systems the probe issupported on.

For probes supported on UNIX and Linux operating systems, probe guides use thestandard UNIX conventions such as $variable for environment variables andforward slashes (/) in directory paths. For example:

$OMNIHOME/probes

For probes supported only on Windows operating systems, probe guides use thestandard Windows conventions such as %variable% for environment variables andbackward slashes (\) in directory paths. For example:

%OMNIHOME%\probes

For probes supported on UNIX, Linux, and Windows operating systems, probeguides use the standard UNIX conventions for specifying environment variablesand describing directory paths. When using the Windows command line withthese probes, replace the UNIX conventions used in the guide with Windowsconventions. If you are using the bash shell on a Windows system, you can use theUNIX conventions.

© Copyright IBM Corp. 2014 v



Note: The names of environment variables are not always the same in Windowsand UNIX environments. For example, %TEMP% in Windows environments isequivalent to $TMPDIR in UNIX and Linux environments. Where such variables aredescribed in the guide, both the UNIX and Windows conventions will be used.

Operating system-specific directory names

Where Tivoli Netcool/OMNIbus files are identified as located within an archdirectory under NCHOME or OMNIHOME, arch is a variable that represents youroperating system directory. For example:

$OMNIHOME/probes/arch

The following table lists the directory names used for each operating system.

Note: This probe may not support all of the operating systems specified in thetable.

Table 2. Directory names for the arch variable

Operating system Directory name represented by arch

AIX® systems aix5

HP-UX PA-RISC-based systems hpux11

HP-UX Integrity-based systems hpux11hpia

Red Hat Linux and SUSE systems linux2x86

Linux for System z® linux2s390

Solaris systems solaris2

Windows systems win32

OMNIHOME location

Probes and older versions of Tivoli Netcool/OMNIbus use the OMNIHOMEenvironment variable in many configuration files. Set the value of OMNIHOME asfollows:v On UNIX and Linux, set $OMNIHOME to $NCHOME/omnibus.v On Windows, set %OMNIHOME% to %NCHOME%\omnibus.

vi IBM Tivoli Netcool/OMNIbus Probe for OPC Unified Architecture (UA): Reference Guide

Chapter 1. IBM Tivoli Netcool/OMNIbus Probe for OPC UnifiedArchitecture (UA)

The IBM Tivoli Netcool/OMNIbus Probe for OPC Unified Architecture (UA)acquires data from devices and element management systems (EMS) that use theOPC UA messaging architecture.

OPC UA is a server-client architecture. The device or EMS acts as the server andthe probe as the client. Communication between them takes place over a SOAPinterface.

The OPC UA server has one or more items under its control. For example, thereading on a thermostat, or the operational status of a piece of machinery. Youconfigure the probe to monitor one or more of these items. The probe registers thisinformation with the OPC UA server. At regular intervals, the OPC UA server pollsthe items to determine if changes have occurred on any of them. The followingtypes of changes can occur, depending on the type of item:v Data changev Status changev Device event

The OPC UA server records each change in a notification.

Also at regular intervals, but not necessarily the same interval, the probe requeststhe OPC UA server to send the notifications it has gathered since the probe askedfor notifications. The probe parses these notifications, converts them intoNetcool/OMNIbus events, and sends them to the ObjectServer.

You can run a pair of probes in a failover configuration where one acts as themaster probe and the other the slave probe. In normal operation, the master probereceives notifications and passes them on to the ObjectServer. Should the masterprobe fail, the slave probe takes over until the master probe is available once more.

You can run a number of probes on a single physical server independently of oneanother. This enables notifications to be processed from a number of sourcessimultaneously.

This guide contains the following sections:v “Summary” on page 2v “Getting started” on page 3v “Installing probes” on page 4v “Data acquisition” on page 7v “Properties and command line options” on page 24v “Running the probe” on page 22v “Elements” on page 32v “Error messages” on page 33v “ProbeWatch messages” on page 42

© Copyright IBM Corp. 2014 1

SummaryEach probe works in a different way to acquire event data from its source, andtherefore has specific features, default values, and changeable properties. Use thissummary information to learn about this probe.

The following table provides a summary of the IBM Tivoli Netcool/OMNIbusProbe for OPC Unified Architecture (UA).

Note: The Probe for OPC UA is based on the OPC Unified Architecture (UA) 1.0.2specification.

Table 3. Summary

Probe target Network devices and EMS that implement the OPC UA1.0.2 specification.

Probe executable name The way in which you run (execute) the probe dependson whether you are running UNIX or Windows:

v UNIX Linux nco_p_opc_ua

v Windows nco_p_opc_ua.bat

Package version 1.0

Probe supported on For details of supported operating systems, see thefollowing Release Notice on the IBM Software Supportwebsite:https://www-304.ibm.com/support/docview.wss?uid=swg21687620

Properties file $NCHOME/omnibus/probes/arch/opc_ua.props

Rules file $NCHOME/omnibus/probes/arch/opc_ua.rules

Sample XML configuration filesfor event and data changenotification

$OMNIHOME/var/OpcUaEvent.xml

$OMNIHOME/var/OpcUaDataChange.xml

%OMNIHOME%\var\OpcUaEvent.xml

%OMNIHOME%\var\OpcUaDataChange.xml

Additional probe files The following additional probe files deliver with theprobe:

v opc_ua_dsl_log.properties - used to configure theadvanced log settings in the Domain-SpecificLanguage (DSL) framework. This is the default filefor the DSSLLogConfig property.

See “Properties and command line options” on page24 for more information.

v generic_opc_ua.jar - generated from the OPCFoundation WSDL set to support probe Web Servicetransactions.

Requirements For details of any additional software that this proberequires, refer to the description.txt file that issupplied in its download package.

Connection method The probe connects to the OPC UA server sessionendpoint using a web service HTTP/SOAP interface.

2 IBM Tivoli Netcool/OMNIbus Probe for OPC Unified Architecture (UA): Reference Guide

https://www-304.ibm.com/support/docview.wss?uid=swg21687620

https://www-304.ibm.com/support/docview.wss?uid=swg21687620

Table 3. Summary (continued)

Multicultural supportAvailable

For information about configuring multiculturalsupport, including language options, see the IBM TivoliNetcool/OMNIbus Installation and Deployment Guide.

Peer-to-peer failover functionality Available

IP environment IPv4 and IPv6

Federal Information ProcessingStandards (FIPS)

IBM Tivoli Netcool/OMNIbus V7.3.0, 7.3.1, 7.4.0, and8.1 use the FIPS 140-2 approved cryptographicprovider: IBM Crypto for C (ICC) certificate 384 forcryptography. This certificate is listed on the NISTwebsite at http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/1401val2004.htm For details aboutconfiguring Netcool/OMNIbus for FIPS 140-2 mode,see IBM Tivoli Netcool/OMNIbus Installation andDeployment Guide.

Getting startedThis section shows how to start the probe with the minimum requiredconfiguration. The procedure assumes that you have a version ofNetcool/OMNIbus installed and running.

Use the following procedure to start the probe with a minimal configuration:

Note: The commands shown in this example are for a Linux system. Adapt thesecommands as necessary for the operating system that your probe server runs.1. Download the probe's installation package following the instructions in

http://www-01.ibm.com/support/knowledgecenter/SSSHTQ/omnibus/probes/all_probes/wip/reference/install_download_intro.html.

2. Edit the probe's properties file and set values for the following:v Server: Set this property to the name of the ObjectServer that the probe

sends events to. The default value of this property is NCOMS.v MessageLevel: Set this property to Debug. This setting provides the maximum

amount of information when the probe is running.v EndpointHttpHost: Set this property to the HTTP host name or IP address of

the OPC UA server host that provides alarms to the probe.v EndpointHttpPort: Set this property to the HTTP port on the OPC UA server

that the probe uses to retrieve alarms.v EndpointSessionServiceName: Set this property to the service name path of

the endpoint on the OPC UA server.v OPCSessionName: Set this property to the name of the probe session on the

OPC UA server to which you want to connect.v MonitoredItemsConfigFile: Set this property to the full path of the XML file

that contains information on the items that the probe is to monitor. Theinformation in this file is used in the OPC UA CreateMonitoredItems service.See “Notification retrieval and synchronization” on page 15 for moreinformation on this file.

3. Ensure that $NCHOME/etc/omni.dat includes information on the ObjectServer.4. Obtain a listing of the probe's command line options to check the probe is

installed correctly:

Chapter 1. IBM Tivoli Netcool/OMNIbus Probe for OPC Unified Architecture (UA) 3

http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/1401val2004.htm

http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/1401val2004.htm

http://www-01.ibm.com/support/knowledgecenter/SSSHTQ/omnibus/probes/all_probes/wip/reference/install_download_intro.html


$NCHOME/omnibus/probes/nco_p_opc_ua -help

5. Start the probe as follows:$NCHOME/omnibus/probes/nco_p_opc_ua \-propsfile $NCHOME/omnibus/probes/linux2x86/opc_ua.props \-messagelevel debug

6. Check the probe's log file to ensure the probe started correctly and is ready toreceive, process, and dispatch events.The probe's MessageLog property provides the name and location of the probe'slog file.

7. Where possible, use a test tool to send events to the probe in order to checkthat the probe processes the events correctly.For example, SoapUI (which allows you to set up a mock service server) andthe OPC Foundation sample server, which provides sample implementations ofOPC UA applications, both servers and clients.See “Using the OPC Foundation sample server” on page 20 for moreinformation on the OPC Foundation sample server.

The probe is now successfully installed and operational. You can now configure theprobe to suit your operating environment.

Installing probesAll probes are installed in a similar way. The process involves downloading theappropriate installation package for your operating system, installing theappropriate files for the version of Netcool/OMNIbus that you are running, andconfiguring the probe to suit your environment.

The installation process consists of the following steps:1. Downloading the installation package for the probe from the Passport

Advantage Online website.Each probe has a single installation package for each operating systemsupported. For details about how to locate and download the installationpackage for your operating system, visit the following page on the IBM TivoliKnowledge Center:http://www-01.ibm.com/support/knowledgecenter/SSSHTQ/omnibus/probes/all_probes/wip/reference/install_download_intro.html

2. Installing the probe using the installation package.The installation package contains the appropriate files for all supportedversions of Netcool/OMNIbus. For details about how to install the probe torun with your version of Netcool/OMNIbus, visit the following page on theIBM Tivoli Knowledge Center:http://www-01.ibm.com/support/knowledgecenter/SSSHTQ/omnibus/probes/all_probes/wip/reference/install_install_intro.html

3. Configuring the probe.This guide contains details of the essential configuration required to run thisprobe. It combines topics that are common to all probes and topics that arepeculiar to this probe. For details about additional configuration that iscommon to all probes, see the IBM Tivoli Netcool/OMNIbus Probe and GatewayGuide.




http://www-01.ibm.com/support/knowledgecenter/SSSHTQ/omnibus/probes/all_probes/wip/reference/install_install_intro.html

http://www-01.ibm.com/support/knowledgecenter/SSSHTQ/omnibus/probes/all_probes/wip/reference/install_install_intro.html

Configuring the probeAfter installing the probe you need to make various configuration settings to suityour environment.

The following table lists the probe's features. For each feature, the table lists theproperties you use to set up that feature, and the section in this guide that showsyou how to set up the feature.

Some features are mandatory for all installations. For those features set theproperties to the correct values or verify that their default values are suitable foryour environment. The remaining features are optional depending on which onesyou want to use.

Table 4. Configuring the probe

Feature Properties See

Mandatory features:

OPC UA connectioninformation

The information needed tocorrectly populate theheader of each requestmessage that the probesends.

RequestHeaderRequestHandleRequestHeaderReturnDiagnosticsRequestHeaderTimeoutHint

“OPC UA communicationsinformation” on page 8

SOAP connectioninformation

The information needed toconnect the OPC UA sessionendpoint (the device orEMS) with the web serviceSOAP interface.

EndpointHttpHostEndpointHttpPortEndpointSessionServiceNameOPCSessionNameMaxResponseMessageSizeRequestedSessionTimeout

“Connecting to the OPC UAserver” on page 9

Notification retrievalinformation

The information needed toretrieve notificationinformation

AcknowledgeAlarmRequestedPublishingIntervalMaxNotificationsPerPublishRequestedLifetimeCountRequestedMaxKeepAliveCountResyncIntervalMonitoredItemsConfigFile

“Notification retrieval andsynchronization” on page 15

ObjectServer host name Server “ObjectServer information”on page 7

Optional features:

Reconnection policy

Specifies whether the probeattempts to reconnect to theOPC UA endpoint followinga communications failure.

RetryCountRetryInterval

“Reconnection and probebackoff strategy” on page 17


Table 4. Configuring the probe (continued)

Feature Properties See

Inactivity policy

Specifies whether the probedisconnects from the OPCUA endpoint following aperiod of inactivity.

Inactivity “Inactivity” on page 18

Data Stream Capture

Allows you to capture thestream of raw data from thetarget device and store it ina file.

StreamCaptureStreamCaptureFilepath

“Data stream capture” onpage 18

Peer-to-peer failover pair

Allows you to set up twoprobes to act as a failoverpair to improve availability.If the master probe shouldstop working, the slaveprobes takes over until themaster is available oncemore.

MessageLogModePeerHostPeerPortPidFilePropsFileRulesFile

“Peer-to-peer failoverfunctionality” on page 19

Use a sample server

Allows you to use a sampleserver.

EndpointHttpHostEndpointHttpPortEndpointHttpServiceEndpointHttpTnsEndpointSessionServiceNameOPCSessionNameMaxResponseMessageSizeRequestedSessionTimeout

“Using the OPC Foundationsample server” on page 20

Running multiple instancesof the probe

Allows you to run two ormore instances of the probeon a single host machine.

NameMessageLogPidFilePropsFileRulesFile

“Running multiple probes”on page 22

Running the probe as aWindows service

None “Running the probe as aWindows service” on page23


Data acquisitionEach probe uses a different method to acquire data. Which method the probe usesdepends on the target system from which it receives data.

The IBM Tivoli Netcool/OMNIbus Probe for OPC Unified Architecture (UA)acquires data from an OPC UA server by issuing publish requests periodically. TheOPC UA server responds by sending any outstanding notifications. The probeparses these notifications into events that it forwards to the ObjectServer.

Data acquisition is described in the following topics:v “ObjectServer information”v “OPC UA communications information” on page 8v “Connecting to the OPC UA server” on page 9v “Notification retrieval and synchronization” on page 15v “Reconnection and probe backoff strategy” on page 17v “Inactivity” on page 18v “Data stream capture” on page 18v “Support for Unicode and non-Unicode characters” on page 19v “Peer-to-peer failover functionality” on page 19v “Using the OPC Foundation sample server” on page 20

ObjectServer informationThe probe sends processed events to an ObjectServer resource. This can be a singleserver or a failover pair of ObjectServers.

The probe sends processed events to an ObjectServer resource. This can be a singleserver or a failover pair of ObjectServers.

Single ObjectServer

Configure the probe to communicate with an ObjectServer by setting the Serverproperty to the name of the ObjectServer.

Failover pair

Optionally, you can define a failover pair of ObjectServers. One of them acts as theprimary ObjectServer that the probe communicates with initially. Should thatObjectServer become unreachable, the probe communicates with the other, backupObjectServer. To define a failover pair set the following probe properties:

Table 5. Properties that define a failover pair of ObjectServers

Property Value

Server Set this property to the name of the primary ObjectServer.

ServerBackup Set this property to the name of the backup ObjectServer.

NetworkTimeout Set this property to the timeout period, in seconds, for the primaryObjectServer. If the probe does not receive a response from the primaryObjectServer within that time, it connects to the backup ObjectServer.

PollServer Set this property to the time period, in seconds, when the probe tries toreconnect to the primary ObjectServer.


Note: Ensure that the value of NetworkTimeout is less than the value of PollServer.

OPC UA communications information

Communication between the probe and the OPC Unified Architecture (UA) serverconsists of a sequence of messages. The probe issues a request, and the serverreturns a response. Each message has two parts:v A header that contains control and security informationv A body that contains the actual request or response

The request header includes a number of parameters that are common to allservice requests. The probe maintains these parameters as properties:

Table 6. Properties used in request headers

Property Usage

RequestHeaderRequestHandle Specifies the requestHandle assigned to oneor more requests. The requestHandle can beused to cancel the requests. All outstandingrequests with the matching requestHandlewill be cancelled.

RequestHeaderReturnDiagnostics An integer value that represents a bit maskthat defines the diagnostic information theserver is to return in the response. Thisvalue appears in the returnDiagnostics fieldof the header.

The value of this property can consist of 0(zero) or a bit value available in the bit maskdefined by the OPC-UA specification. Thedefault value of 64 (0x0000 0040) indicatesthat the diagnostics to return is"OperationalLevel / LocalizedText".Specifying no value indicates thatdiagnostics are not to be returned.

The content of the diagnostic information isvendor-specific. Refer to the documentationfor the OPC UA device your site uses forinformation about return diagnosticinformation.

RequestHeaderTimeoutHint Specifies the timeout period (in milliseconds)for all HTTP requests sent to the OPC UAserver. This value appears in thetimeoutHint field of the header.

For a server this timeout is only a hint andcan be used to cancel long runningoperations to free resources. If the serverdetects a timeout, it can cancel the operationby sending the Service result Bad_Timeout.The server should wait for the specifiedtimeout period after it received the requestbefore cancelling the operation. Specifying avalue of 0 indicates no timeout period.

Ensure that all these properties have values that are suitable for the needs of yoursite.


Connecting to the OPC UA serverThe probe uses an exchange of SOAP messages that encapsulate various OPCUnified Architecture (UA) services to establish a connection with the EMS.

The process of connecting to the OPC UA server has the following stages:1. “Creating a secure channel.”2. “Creating a OPC UA session.”3. “Activating the OPC UA session” on page 11.

The following sections summarize the actions in each stage and highlight theproperties that the probe uses in each stage.

Creating a secure channel

The probe uses secure transport layer (SSL) to enable a secured HTTPStransmission. You can choose to use HTTP (non-secured) or HTTPS by configuringEnableSSL and setting the keystore/truststore.

Creating a OPC UA session

Once the secure channel is established the probe creates an OPC UA session withthe OPC UA server using the OPC UA CreateSession service. This service has anumber of parameters that define the characteristics of the session. The probemaintains values for some of the parameters as properties.


Table 7. Properties used in the CreateSession service

Properties Usage

EndpointHttpHostEndpointHttpPortEndpointSessionServiceName

The probe uses these properties to constructthe URL of the OPC UA server as follows:

http://host:port/service

Where:

v host is the value of the EndpointHttpHostproperty. This value can either be ahostname or an IP (IPv4/IPv6) address.

If you specify an IPv6 address, ensure thatthe address is enclosed in [] (squarebrackets). For example, as a value in theproperties file:

EndpointHttpHost:’[2001:15f8:106:195:250:56ff:fe9c:5183]’

For example, in the command line:

-httphost[2001:15f8:106:195:250:56ff:fe9c:5183]

v port is the value of the EndpointHttpPortproperty.

v service is the value of theEndpointSessionServiceName property.

In addition, if the EndpointWsdlLocationproperty is empty (by default), the probewill use the formed URL to reach the WSDLlocation. The formed URL ishttp://host:port/server?wsdlhttp://<EndpointHttpHost>:<EndpointHttpPort>/<EndpointSessionServiceName>.

OPCSessionName The name for the OPC UA session.

RequestedSessionTimeout The maximum amount of time (inmilliseconds) that the session can remain inuse without communications activity takingplace. If the probe fails to issue a Servicerequest within this interval, then the OPCUA server automatically terminates thesession.

Make sure that the value of this property isgreater than the value of theResynchInterval property.

MaxResponseMessageSize The maximum size (in bytes) of the body ofany message that the OPC UA server sendsto the probe.

Ensure that all these properties have values that are suitable for the needs of yoursite.


Activating the OPC UA session

Having created the OPC UA session, the probe uses the OPC UA ActivateSessionservice to bring it into use.

Establishing a secure connection to the OPC UA serverThe probe uses an exchange of SOAP messages that encapsulate various OPCUnified Architecture (UA) services to establish a connection with the EMS.

To establish a secure communication between the probe and the OPC UA server,you should use an SSL connection with HTTPS. Such a connection significantlyreduces the vulnerabilities of hijacked sessions and passwords.

Configuring SSL connectionsIf the OPC UA server is using a Secure Socket Layer (SSL) connection to encryptdata exchanged over JMS and HTTP, you will need to configure the truststore forthe HTTPS connection on the Tivoli Netcool/OMNIbus probe server. This is theserver on which the probe is running.

Summary of SSL configuration

The SSL configuration requires that you perform some tasks on the OPC UnifiedArchitecture (UA) server and some tasks on the Tivoli Netcool/OMNIbus probeserver. The following list summarizes these tasks:v On the OPC UA server:

– Obtain the OPC UA server security certificate from the certificate authority(CA) or use a self-signed certificate.

– Import the CA or self-signed certificate into the server truststore.– Export the server truststore (which contains the CA or self-signed certificate)

into a certificate file that can be handed to the client (probe).– Or, export the OPC UA server keystore file.

v On the Tivoli Netcool/OMNIbus probe server (client):– Import the OPC UA server security certificate or import the OPC UA server

keystore file.– Verify either the OPC UA server security certificate or the OPC UA server

keystore file.– Configure the probe either for one-way SSL connection or for two-way SSL

connection.

Note: You can obtain the probe server (client) security certificate from the CAand use it directly in SSL configuration. Or, you can create a clienttruststore/keystore that includes the CA security certificate. You use the keytoolutility to create a truststore that includes the CA certificate or you can importthe CA certificate into an existing truststore.

Performing SSL configuration on the OPC UA server

To perform SSL configuration on the OPC UA server, use the following steps:

Note: For more details about configuring SSL security for the OPC UA server(including instructions about obtaining certificate files), refer to your vendorserver's SSL configuration guide.


1. Either obtain the OPC UA server security certificate from the certificateauthority (CA) or use a self-signed certificate.

2. Import the CA or self-signed certificate into the server truststore.3. If you have the appropriate user access, export the OPC UA server truststore

into a certificate file on the OPC UA server that can be handed to the client(probe). To export the OPC UA server keystore file into a certificate file on theOPC UA server, use the following command:

./keytool -export -alias alias_name -keystore keystore_file -storepasspassword -file certificate_file

Where:alias_name - Specifies the keystore alias specified during OPC UA serverkeystore generation, for example: OPCUA.keystore_file - Specifies the path to and name of the OPC UA server keystorefile, for example: /opt/opcuaserver/opcua.keystore .password - Specifies the OPC UA server keystore password, for example: thepassword of opcua.keystore.certificate_file - Specifies the path to and name of the certificate file to becreated, for example: /opt/opcuacert/opcuaprobecert.

Performing SSL configuration on the probe server

Note: You should now have an OPC UA server certificate file that resides on theOPC UA server. You will import the OPC UA server certificate file as part of theSSL configuration on the probe server.

To perform SSL configuration on the probe server, use the following steps:1. Import the OPC UA server certificate file either into an existing truststore or into

a new truststore.a. To import the OPC UA server certificate file into an existing truststore, you

need to point an alias to a key entry as the certificate reply. The alias mustbe the same as that specified during OPC UA server keystore filegeneration, for example:

./keytool -import -trustcacerts -alias alias_name -file certificate_file-keystore truststore_file -storepass password

b. To import the OPC UA server certificate file into a new truststore, make surethat the alias that you specify does not already exist in your truststore, forexample:

./keytool -import -trustcacerts -alias new_alias_name -filecertificate_file -keystore truststore_file -storepass password

In the preceding examples (Step 1a and Step 1b):alias_name - Is the keystore alias specified during OPC UA server keystoregeneration, for example: OPCUA.new_alias_name - Specifies the keystore alias of a new keystore, for example:opcuaprobe.certificate_file - Specifies the path to and name of the certificate filecreated on the OPC UA server, for example: /opt/opcuacert/opcuaprobecert.truststore_file - Specifies the path to and name of the truststore file onthe Tivoli Netcool/OMNIbus probe server that will contain the importedcertificate, for example: /opt/tivoli/opcuaprobe.truststore .


password - Specifies the OPC UA server keystore password, for example: thepassword of opcuaserver.truststore.

2. Verify that the certificate has been imported into the keystore using thefollowing command:

./keytool -list -v -keystore truststore_file

Where:truststore_file - Specifies the path to and name of the truststore filegenerated on the probe server, for example: /opt/tivoli/opcuaprobe.truststore.

Configuring the probe for one-way SSL connection

To configure the probe to connect to the OPC UA server using a one-way SSLconnection, use the following steps:

Note: A one-way SSL connection does not require client authentication. For aone-way SSL connection, you configure the EnableSSL property and the truststorerelated properties (TrustStore, TrustStorePassword, and TrustStoreType).1. Set the probe's EnableSSL property to true and configure the probe's

EndpointHttpPort property to your OPC UA server's HTTPS port. You can useany valid HTTPS port based on your OPC UA server configuration.

2. Specify values for the following probe properties:v TrustStore - Specify the path of the probe's keystore that you created in the

steps for importing the certificate, for example: /opt/opcua.trustStore.v TrustStorePassword - Specify the password that you set for the specified

keystore in the TrustStore property.v TrustStoreType - Specify the truststore type obtained from the truststore. For

example, JKS (Java Keystore).

Note: TrustStoreType has a default value of JKS (which represents JavaKeystore). If you are using another type such as .pfx, then configure theTrustStoreType to the value PKCS12.

Configuring the probe for two-way SSL connection

To configure the probe to connect to the OPC UA server using a two-way SSLconnection, use the following steps:

Note: A two-way SSL connection requires client authentication. This type of SSLconnection is often referred to as required client authentication. For a two-way SSLconnection, you configure the EnableSSL property, the truststore related properties(TrustStore, TrustStorePassword, and TrustStoreType), and the keystore relatedproperties (KeyStore, KeyStorePassword, and KeyStoreType).1. Set the probe's EnableSSL property to true and configure the probe's

EndpointHttpPort property to use the default OPC UA server HTTPS port,51511.

Note: You can use any valid HTTPS port based on your OPC UA serverconfiguration. For the OPC Foundation sample application (the sample server)the default HTTPS port is 51212.

2. Create a keystore on the Tivoli Netcool/OMNIbus probe server. Specify valuesappropriate to your environment for the following properties:


v TrustStore - Specify the path of the probe's keystore that you created in thesteps for importing the certificate, for example: /opt/opcua.trustStore.

v TrustStoreType - Specify the truststore type obtained from the truststore. Forexample, JKS (Java Keystore).

Note: TrustStoreType has a default value of JKS (which represents JavaKeystore). If you are using another type such as .pfx, then configure theTrustStoreType to the value PKCS12.

v TrustStorePassword - Specify the password that you set for the specifiedkeystore in the TrustStore property.

v KeyStore - Specify the path of the probe's keystore that you created in thesteps for importing the client certificate if client authentication is required.For example, /opt/opcua.trustStore (if the client certificate was importedthere), or /opt/opcua.keyStore (if the client certificate is a separate keystore).

v KeyStoreType - Specify the keystore type obtained from the keystore. Forexample, JKS (Java Keystore).

Note: KeyStoreType has a default value of JKS. If you are using another typesuch as .pfx, then configure the KeyStoreType to the value PKCS12.

v KeyStorePassword: Specify the password that you set for the specifiedkeystore in the KeyStore property.

Example one-way SSL configuration property settings

The following example shows SSL configuration settings from the properties file ofan example Probe for OPC UA for one-way SSL. Replace the sample values withthose appropriate to your environment.EndpointHttpHost : "localhost"EndpointHttpPort : 51511EnableSSL : "true"TrustStore : "/opt/opcua.trustStore"TrustStorePassword : "newpassword"

Example two-way SSL configuration property settings

The following example shows SSL configuration settings from the properties file ofan example Probe for OPC UA for two-way SSL. This example shows that thekeystore property related values reuse the values specified for the truststore relatedproperty values. Replace the sample values with those appropriate to yourenvironment.EndpointHttpHost : "localhost"EndpointHttpPort : 51511EnableSSL : "true"TrustStore : "/opt/opcua.trustStore"TrustStorePassword : "newpassword"TrustStoreType : "JKS"KeyStore : "/opt/opcua.trustStore"KeyStore Password : "newpassword"KeyStore Type : "JKS"

The following example shows SSL configuration settings from the properties file ofan example Probe for OPC UA for two-way SSL. This example shows that thekeystore property related values (except for the type) are different from the valuesspecified for the truststore related property values. Replace the sample values withthose appropriate to your environment.


EndpointHttpHost : "localhost"EndpointHttpPort : 51511EnableSSL : "true"TrustStore : "/opt/opcua.trustStore"TrustStorePassword : "newpassword"TrustStoreType : "JKS"KeyStore : "/opt/opcua.keyStore"KeyStore Password : "keypassword"KeyStore Type : "JKS"

Notification retrieval and synchronizationThe probe identifies one or more items in the server address space that it wants tomonitor. The OPC Unified Architecture (UA) server regularly polls each item. Ifthere has been a suitable change in the item's value or state, the OPC UA servergenerates a notification. The probe regularly retrieves these notifications.

The process of retrieving notifications from the OPC UA server has the followingstages:1. “Setting up a subscription”2. “Defining the items to monitor” on page 163. “Performing the initial synchronization” on page 164. “Retrieving notifications” on page 16

Setting up a subscription

When it has established a connection and session with the OPC UA server, theprobe creates a subscription which is used to report notifications to the probe.Later in the process, the probe associates a number of items to monitor with thesubscription.

The probe uses the OPC UA service CreateSubscription to set up the subscription.The service has a number of parameters that define the characteristics of thesubscription. The probe maintains the values of some parameters as properties.

Table 8. Properties used in the CreateSubscription service

Property Usage

RequestedPublishingInterval The frequency (in milliseconds) that theOPC UA server is to gather notificationsfrom the monitored items and queue themready for transmission to the probe.

MaxNotificationPerPublish The maximum number of notifications thatthe probe wants to receive in a singleresponse from the OPC UA server.

RequestedLifetimeCount The maximum lifetime counter for thesubscription. If this number of publishingintervals occurs without the OPC UA serverreceiving a request from the probe to sendoutstanding notifications, the server deletesthe subscription.

Ensure that the value of this property is atleast three times greater than the value ofRequestedMaxKeepAliveCount.


Table 8. Properties used in the CreateSubscription service (continued)

Property Usage

RequestedMaxKeepAliveCount The maximum keep-alive counter for thesubscription. If this number of publishingintervals occurs without there being anynotifications to return to the probe, the OPCUA server sends a keep-alive message toensure the subscription remains in use.

When the server publishing timer hasexpired this number of times withoutrequiring any NotificationMessage to besent, the Subscription sends a keep-aliveMessage to the probe. The negotiated valuefor this parameter is returned in theresponse. If the requested value is 0 (zero),the server revises the counter with thesmallest supported keep-alive count.

In response to the request to create a subscription, the OPC UA server returns anidentifier for the subscription. The probe retains this for use when telling theserver which items to monitor and when asking the EMS to return anyoutstanding notifications.

Defining the items to monitor

With the subscription in place, the probe can define the set of items that it wantsthe OPC UA server to monitor. The probe uses the OPC UA CreateMonitoredItemservice to create the set of monitored items on the server. The service has a numberof parameters, some of which the probe holds in an XML file. There is one probeproperty that defines the name and location of that file.

Table 9. Property used in the CreateMonitoredItem service

Property Usage

MonitoredItemsConfigFile The full path of a file that defines the itemsto monitor and any notification filters. Theuse of a filter is optional.

Chapter 2, “The XML configuration files forevent and data change notifications,” onpage 45 has a detailed description of the file,its structure, and its content.

Performing the initial synchronization

After defining the items to monitor, the probe immediately retrieves a list of allactive notifications from the OPC UA server if the InitialResync property is set totrue. When the InitialResync property is set to false, the probe does not receivethe existing notifications.

Retrieving notifications

The probe periodically requests the OPC UA server to return any outstandingnotifications. The probe uses the OPC UA Publish service to do this, and the


frequency of publishing requests is determined by the value of the ResyncIntervalproperty. In response to each request, the OPC UA server returns any notificationsthat are waiting on its notification queue.

The probe parses each notification, converts it to an ObjectServer event, and sendsthat event to the ObjectServer.

Under certain conditions, the OPC UA server may have more notifications to sendthan the probe can readily handle. Use the MaxNotificationPerPublish property tolimit the number of notifications the server can send in response to each Publishrequest. This helps to ensure that the probe is not overloaded during an eventstorm.

As stated previously, if the user enables the InitialResync property, the proberetrieves notifications immediately after the monitored items are created.Otherwise, if the user does not enable the InitialResync property, the probe waitsuntil the time specified in the ResyncInterval property expires to initiate therequest for the notifications from the OPC UA server.

Acknowledging notifications

A Publish request can include acknowledgments of notifications the probe hasreceived. The AcknowledgeAlarm property controls whether the probe acknowledgesnotifications. If this property is set to 1, the probe acknowledges notifications. Ifthis property is set to 0, the probe does not acknowledge alarms.

Reconnection and probe backoff strategyUse the RetryCount and RetryInterval properties to specify how the probe reactsif the connection to the OPC Unified Architecture (UA) server is lost or cannot beestablished.

Use the RetryCount property to specify whether the probe attempts to reconnect tothe server. Setting the property to 0, the default value, means that the probe doesnot try to reconnect and simply shuts down. Any other, positive value specifies thenumber of times the probe tries to reconnect before shutting down.

Use the RetryInterval property to specify the number of seconds between eachattempt to reconnect to the server. Setting the property to 0 means that the probeuses an exponentially increasing interval between connection attempts. First theprobe waits 1 second, then 2 seconds, then 4 seconds, and so on up to a maximumof 4095 seconds. If this limit, or the number of connection attempts is reached, theprobe shuts down.


InactivityThe probe can disconnect from the OPC Unified Architecture (UA) server and shutdown if there is no event activity for a predefined amount of time.

You can use the Inactivity property to specify how long, in seconds, the probewaits before disconnecting from the OPC UA server and shutting down. If theprobe receives no events during that time, it disconnects from the server and shutsdown. To ensure that the probe never disconnects from the server, set the value ofthe property to 0, which is the default value.

Data stream captureThe probe can capture the stream of SOAP messages exchanged with the OPCUnified Architecture (UA) server and store it in a file. The data can be used forproblem solving, debugging purposes, to develop new features for the probe, or topass onto other management systems that require the same data.

To capture the data stream in log files, use the following procedure:1. Set the value of the StreamCapture property to 1.2. Set the value of the StreamCaptureFilePath property to the full path of a

directory to hold the files of data.

Notes:

v Specify the full path of the directory. For example:/opt/tivoli/netcool/omnibus/var

v You cannot include variables such as $OMNIHOME in the directory path.v If the directory does not exist, or StreamCaptureFilePath does not have a

value, the probe stores the file in the directory that the probe was run from.That is, $NCHOME/omnibus/probes on a Linux or Unix system, or%NCHOME%\omnibus\probes\win32 on a Windows system.

3. If the probe is running, restart the probe.

The probe now writes data to a file in the specified directory. The name of that filehas the following format:

probename_soapws-timestamp.data

Where:probename is the name of the probe defined in the Name property.timestamp is the UTC time (expressed in milliseconds) when the file wascreated.

Example:opc_ua_soapws-1402475122604.data

Note: Capturing the data stream to a log file generates a lot of data, consumingdisk space and other system resources. So use this feature with caution. As soon asyou no longer require the capture of data, set the value of the StreamCaptureproperty to 0 and restart the probe.


Support for Unicode and non-Unicode charactersThe probe can process multibyte characters such as Unicode UTF-8, GB, Big5, orShift-JIS.

Use the following procedure to set up the probe to process multibyte characters:1. Ensure that the OPC Unified Architecture (UA) server is configured to send

data in the required format (for example, UTF-8).2. Set the required locale on the system that runs the probe.

Table 10. Setting the locale for multibyte characters

Operatingsystem Procedure to set the locale

Linux and Unix Set the locale by changing the values of the LANG and LC_ALLenvironment variables. For example, to set the locale to simplifiedChinese in UTF-8, use the following commands:

export LANG=zh_CN.UTF-8export LC_ALL=zh_CN.UTF-8

Windows1. Open the Control Panel and double click on Regional and

Language.

2. On the Formats tab, select the language from the list in Format.

3. On the Administrative tab, click Change system locale.

4. Select the language from the list in Current System Locale.

5. Click OK.

6. Click OK.

3. Configure the ObjectServer to enable the insertion of data that uses the requiredcharacter set. The IBM Tivoli Netcool/OMNIbus Administration Guide shows howto create, configure, and run an ObjectServer in UTF-8 mode or using anothercharacter set.

4. Run the probe or, if it is already running, restart the probe.When running the probe on a Windows system using a UTF-8 character set,always specify the -utf8enabled command line option. For all other charactersets, do not use the -utf8enabled command line option.

Peer-to-peer failover functionalityThe probe supports failover configurations where two probes run simultaneously.One probe acts as the master probe, sending events to the ObjectServer; the otheracts as the slave probe on standby. If the master probe fails, the slave probeactivates.

While the slave probe receives heartbeats from the master probe, it does notforward events to the ObjectServer. If the master shuts down, the slave probe stopsreceiving heartbeats from the master and any events it receives thereafter areforwarded to the ObjectServer on behalf of the master probe. When the master isrunning again, the slave continues to receive events, but no longer sends them tothe ObjectServer.


Example property file settings for peer-to-peer failover

You set the peer-to-peer failover mode in the properties files of the master andslave probes. The settings differ for a master probe and slave probe.

Note: In the examples, make sure to use the full path for the property value. Inother words replace $OMNIHOME with the full path. For example:/opt/IBM/tivoli/netcool.

The following example shows the peer-to-peer settings from the properties file of amaster probe:Server : "NCOMS"RulesFile : "master_rules_file"MessageLog : "master_log_file"PeerHost : "slave_hostname"PeerPort : 5555 # [communication port between master and slave probe]Mode : "master"PidFile : "$OMNIHOME/var/opc_ua"

The following example shows the peer-to-peer settings from the properties file ofthe corresponding slave probe:Server : "NCOMS"RulesFile : "slave_rules_file"MessageLog : "slave_log_file"PeerHost : "master_hostname"PeerPort : 5555 # [communication port between master and slave probe]Mode : "slave"PidFile : "$OMNIHOME/var/opc_ua2"

Using the OPC Foundation sample serverThe OPC Foundation provides sample implementations of OPC UnifiedArchitecture (UA) applications, both servers and clients. You can use a sampleOPC Foundation sample server application with the probe for evaluation andtesting purposes.

To use a sample OPC UA server, configure the probe's properties as follows:1. Set the values of the following properties as shown in “Connecting to the OPC

UA server” on page 9:EndpointHttpHost

EndpointHttpPort

EndpointSessionServiceName

OPCSessionName

RequestedSessionTimeout

MaxResponseMessageSize

The documentation for the OPC Foundation sample server may containguidance on how to configure these properties. For example, there may beinformation on the range of values that RequestedSessionTimeout andMaxResponseMessageSize can have.

2. In addition, set the following properties to the shown values:EndpointHttpService="SessionEndpoint"EndpointHttpTns="http://opcfoundation.org/UA/2008/02/Services.wsdl"

3. Download all of the WSDL and XSD sets that the OPC Foundation sampleserver application uses.


a. Download the Services.wsdl set and save it to a file name of your choice,for example, Services.wsdl:http://localhost:10000/Quickstarts/DataAccessServer/None?wsdl

b. Download the Services0.wsdl set and save it to a file name of your choice,for example, Services0.wsdl:http://localhost:10000/Quickstarts/DataAccessServer/None?wsdl=wsdl0

c. Download the Type.xsd set and save it to a file name of your choice, forexample, Type.xsd:http://localhost:10000/Quickstarts/DataAccessServer/None?xsd=xsd1

d. Download the Serialization.xsd set and save it to a file name of yourchoice, for example, Serialization.xsd:http://localhost:10000/Quickstarts/DataAccessServer/None?xsd=xsd0

4. Save the files that contain the downloaded WSDL and XSD sets in a localdirectory. For example:C:/temp

5. Modify the location and schemaLocation fields in the URLs associated with thefiles for these WSDL and XSD sets.

Note: These URLs are located in the sets you downloaded and saved to files instep 3 (for example, Services.wsdl, Services0.wsdl, Type.xsd, andSerialization.xsd).a. The following example shows the original values specified for the location

and schemaLocation fields for one of these sets. The fields that need to bemodified appear in this typeface:<wsdl:import namespace="http://tempuri.org/"location="http://localhost:10000/Quickstarts/DataAccessServer/None?wsdl=wsdl0"/>

<xsd:import schemaLocation="http://localhost:10000/Quickstarts/DataAccessServer/None?xsd=xsd1"namespace="http://opcfoundation.org/UA/2008/02/Types.xsd"/>

<xsd:import schemaLocation="http://localhost:10000/Quickstarts/DataAccessServer/None?xsd=xsd0"namespace="http://schemas.microsoft.com/2003/10/Serialization/"/>

b. The following example shows the URLs after modifying the values for thelocation and schemaLocation fields. Replace these values with the file paththat you specified. The fields that were modified appear in this typeface:<wsdl:import namespace="http://tempuri.org/"location="file:/C:/temp/Services0.wsdl"/>

<xsd:import schemaLocation="file:/C:/temp/Types.xsd"namespace="http://opcfoundation.org/UA/2008/02/Types.xsd"/>

<xsd:import schemaLocation="file:/C:/temp/Serialization.xsd"namespace="http://schemas.microsoft.com/2003/10/Serialization/"/>

Do this for all of the sets that you downloaded.6. Configure the following properties to values associated with where the OPC

Foundation sample server is actually running. Replace the following valueswith values appropriate for your environment:EndpointHttpHost: "localhost"EndpointHttpPort: 10000EndpointSessionServiceName: "Quickstarts/DataAccessServer/None"EndpointWsdlLocation : ’file:/C:/temp/Services.wsdl’

7. Start the probe and it connects to the sample server.


The documentation for the sample server shows how to create and send eventsto the probe.

8. When you have finished testing or evaluating the probe, reconfigure it tocommunicate with the product environment. In particular return theEndpointHttpService and EndpointHttpTns properties to their original values:EndpointHttpService="UAService"EndpointHttpTns="http://opcfoundation.ord/UA/2008/02/Endpoints.wsdl"

Running the probeThe way in which you run the probe depends on whether you are running UNIXor Windows.

To start the probe, use the following command:

UNIX Linux $NCHOME/omnibus/probes/nco_p_opc_ua

Windows %NCHOME%\omnibus\probes\win32\nco_p_opc_ua.bat

Running multiple probesYou can run multiple, concurrent instances on a single host machine.

Preparation

For each instance of the probe that you want to run, do the following:1. Create a uniquely-named copy of the probe's properties file, for example:

$NCHOME/omnibus/probes/arch/opc_ua_n.props

For each copy of the properties file, replace n with a unique number.2. Optionally, create a uniquely-named copy of the probe's rules file. Customize

the copy as required.3. In the properties file for each instance, define a unique value for the following

properties:Name

MessageLog

PidFile

4. In the properties file for each instance, set the values of the PropsFile andRulesFile properties to the names of the files you created in steps 1 and 2.

Running the probes

To run each instance of the probe, specify the -propsfile command line option torefer to the appropriate properties file, for example on UNIX:

Note: Use the full file path (and not the $NCHOME environment variable) afterthe -propsfile option on the command line to specify the location of theproperties files. Typically, the $NCHOME environment variable is defined as/opt/IBM/tivoli/netcool.$NCHOME/omnibus/probes/nco_p_opc_ua-propsfile /opt/IBM/tivoli/netcool/omnibus/probes/aix5/opc_ua_1.props

$NCHOME/omnibus/probes/nco_p_opc_ua-propsfile /opt/IBM/tivoli/netcool/omnibus/probes/aix5/opc_ua_2.props


Running the probe as a Windows serviceThe Windows version of the probe can run as a Windows service.

Registering and running the Windows service

To run a single instance of the probe as a Windows service:1. Open a Command Prompt.2. Register the probe as a Windows service:

%OMNIHOME%\probes\win32\nco_p_opc_ua.bat /INSTALL /INSTANCE instance-name/CMDLINE "command-line-options"

Replace instance-name with a unique name for the service andcommand-line-options with any command line options that you want to usewhen running the probe. Always enclose the command line options in quotes.If you do not want to use any command line options, exclude the /CMDLINEswitch.

Note: If you exclude the /INSTANCE switch, the name of the service isNCONcoPOpcUaProbe.Example:%OMNIHOME%\probes\win32\nco_p_opc_ua.bat /INSTALL /INSTANCE OpcUaProbe1/CMDLINE "-utf8enabled"

Note: Ensure that the %OMNIHOME% environment variable is defined as asystem variable.

Note: If you define the %OMNIBUS_JVM_DLL% environment variable, theprobe uses that dynamic link library (DLL) for the windows service. Otherwise,by default, the probe uses the j9vm\jvm.dll that comes with TivoliNetcool/OMNIbus.

3. Run the service:a. Open the Windows Control Panel and double click Administrative Tools.b. Double click Services.c. Click on the entry for the probe service and click Start.

Removing the service

To remove the service, if required:1. Stop the service, if it is running:

a. Open the Windows Control Panel and double click Administrative Tools.b. Double click Services.c. Click on the entry for the probe service and click Stop.

2. Open a Command Prompt and enter the following command to remove theprobe service from the system:%OMNIHOME%\probes\win32\nco_p_opc_ua.bat /REMOVE /INSTANCE instance-name

Replace instance-name with the instance name you supplied when registeringthe probe as a service.


Properties and command line optionsYou use properties to specify how the probe interacts with the device. You canoverride the default values by using the properties file or the command lineoptions.

The following table describes the properties and command line options specific tothis probe. For information about properties and command line options common toall probes, see the IBM Tivoli Netcool/OMNIbus Probe and Gateway Guide. Assupplied the location and name of the properties file is $NCHOME/omnibus/probes/arch/opc_ua.props.

Table 11. Properties and command line options

Property name Command line option Description

AcknowledgeAlarm string -ackalarm (This isequivalent toAcknowledgeAlarm with avalue of true.)

-noackalarm (This isequivalent toAcknowledgeAlarm with avalue of false.)

Use this property to specifywhether the probe shouldacknowledge alarms that havebeen received. This property takesthe following values:

v false: The probe does notacknowledge alarms that havebeen received.

v true: The probe acknowledgesalarms that have been received.

The default is false.

ActivateSessionLocaleId string

-activatesessionlocaleidstring

Use this property to define thelocale id in property order forlocalized strings used in anActivateSession request. Use the ;(semicolon) delimeter to constructa list of locale ids.

The default is en-US.

DSLLogConfig string -dsllogconfig string Use this property to specify thename of the configuration file forthe DSL framework; theframework carries out detailedlogging of the probe's components.The location of the configurationfile is $NCHOME/omnibus/probes/java or %OMNIHOME%\probes\win32.

The default is:opc_ua_dsl_log.properties


Table 11. Properties and command line options (continued)


EnableSSL string -ssl (This is equivalent toEnableSSL with a value oftrue.)

-nossl (This is equivalentto EnableSSL with a valueof false.)

Use this property to specifywhether connectivity between theprobe and the OPC UA server isenabled. This property takes thefollowing values:

v false: Disables SSL connectivitybetween the probe and the OPCUA server.

v true: Enables SSL connectivitybetween the probe and the OPCUA server.


EnableSSLDebug string -ssldebug (This isequivalent toEnableSSLDebug with avalue of true.)

-nossldebug (This isequivalent toEnableSSLDebug with avalue of false.)

Use this property to specifywhether SSL debug messages areenabled. This property takes thefollowing values:

v false: Disables SSL debugmessages.

v true: Enables SSL debugmessages.


EndpointHttpHost string -httphost string Use this property to specify theHTTP host name or IP address(IPv4 or IPv6) of the OPC UAserver.

The default is: localhost.

EndpointHttpPort integer -httpport integer Use this property to specify theport on the HTTP server to use foralarm retrieval.

The default is: 51511.

EndpointHttpServicestring

-httpservice string Use this property to specify thename of the OPC UA service namethat the probe uses tocommunicate with the OPC UAserver. The property takes thefollowing values:

UAService: Use this value whenconnecting to a server that usesthe standard WSDL supplied bythe OPC Foundation.

SessionEndpoint: Use this valuewhen connecting to one of thesample servers that the OPCFoundation supplies.

The default is: UAService.




EndpointHttpTns string -httptns string Use this property to specify theURI of the WSDL file that theprobe uses when communicatingwith the OPC UA server. Theproperty takes the followingvalues:

http://opcfoundation.org/UA/2008/02/Endpoints.wsdl: Use thisvalue when connecting to a namespace that uses the standardWSDL supplied by the OPCFoundation.

http://opcfoundation.org/UA/2008/02/Services.wsdl: Use thisvalue when connecting to one ofthe sample servers that the OPCFoundation supplies.

The default is:http://opcfoundation.org/UA2008/02/Endpoints.wsdl

EndpointSessionServiceName string

-endpointsessionservicename string

Use this property to specify thename of the session on the OPCUA server to use for alarmretrieval.

The default is: UAEndpoints

EndpointWsdlLocationstring

-wsdllocation string Use this property to specify thelocation of the WSDL file that theprobe uses to connect to the OPCUA server. This property cancontain the path of a local WSDLfile or the URL of a publishedWSDL file.

The default is: "".

The following is an example of aURL to specify the location of alocal WSDL file:

EndpointWsdlLocation:"file:/C:/wsdl/Opc.Ua.SessionEndpoint"

The following is an example of aURL to specify the location of apublished WSDL file:

EndpointWsdlLocation:"http://opcfoundation.org/UA/2008/02/Endpoints?wsdl"




Inactivity integer -inactivity integer Use this property to specify thelength of time (in seconds) thatcan pass without the probereceiving events. If this timeexpires, the probe disconnectsfrom the target system and shutsdown. A value of 0 means that theprobe never shuts down.

The default is: 0.

InitialResync string -initialresync string Use this property to specifywhether the probe resynchronizeswith the target system after youdefine the items to monitor. Theproperty takes the followingvalues:

true: After you define the items tomonitor, the probe resynchronizeswith the target system.

false: The probe does notresynchronize with the targetsystem.

The default is true.

KeyStore string -keystore string Use this property to specify the filename (with full path) of thekeystore file that contains theclient certificate for SSL, if clientauthentication is required.

The default is: "".

KeyStorePassword string

-keystorepassword string Use this property to specify thepassword required to access thecertificate specified by theKeyStore property.

The default is: "".

KeyStoreType string -keystoretype string Use this property to specify thekeystore type obtained from thekeystore, for example: JKS, PKCS12,and so forth.

The default is: JKS.

MaxNotificationPerPublish integer

-maxnotificationperpublishinteger

Use this property to specify themaximum number of notificationsthat the OPC UA server can returnin response to a single Publishrequest. The value of this propertyis used as a parameter for the OPCUA CreateSubscription service.

The default is: 500 notifications.




MaxResponseMessageSizeinteger

-maxresponsemessagesizeinteger

Use this property to specify themaximum size (in bytes) of thebody in any SOAP message theOPC UA server sends to the probe.The value of this property is usedas a parameter for the OPC UACreateSession service.


MonitoredItemsConfigFile string

-monitoreditemsconfigfilestring

Use this property to specify thefull path of the XML file thatcontains information on the itemsthat the probe is to monitor. Theinformation in this file is used inthe OPC UACreateMonitoredItems service.

The default value is:$OMNIHOME/var/OpcUaEvent.xml.

Note: You need to manuallyconfigure this property to theactual path without using the$OMNIHOME or $NCHOMEenvironment variables.

OPCSessionName string -opcsessionname string Use this property to specify thesession name to use whenconnecting to the OPC UA server.The value of this property is usedas a parameter for the OPC UACreateSubscription service.

The default is: OPC client.

PidFile string -pidfile string Use this property to define the filethat contains the process ID for thedevice.

RequestedLifetimeCountinteger

-lifetimecount integer Use this property to specify themaximum number of times thepublishing interval can occurwithout the server receiving aPublish request from the probebefore the server deletes thesubscription. The value of thisproperty is used as a parameter forthe OPC UA CreateSubscriptionservice.

Ensure that the value of thisproperty is three times the value ofthe RequestedMaxKeepAliveCountparameter.





RequestedMaxKeepAliveCount integer

-maxkeepalivecount integer When the publishing interval hasoccurred a set number of timesand there are no notifications topublish, the OPC UA server sendsa keep-alive message to the probe.Use this property to specify thenumber of times the publishinginterval can occur before sending akeep-alive message. The value ofthis property is used as aparameter for the OPC UACreateSubscription service.


RequestedPublishingInterval integer

-publishinginterval integer For each subscription, the OPC UAserver periodically samples themonitored items and generatesnotifications if necessary. Use thisproperty to define that sampleinterval (in milliseconds). Thevalue of this property is used as aparameter for the OPC UACreateSubscription service.


RequestedSessionTimeoutinteger

-sessiontimeout integer Use this property to specify howlong (in milliseconds) the OPC UAsession should remain open whenthere is no activity. The value ofthis property is used as aparameter for the OPC UACreateSession service.


RequestHeaderRequestHandle integer

-requesthandle integer Use this property to specify thenumber to use as the requesthandle in the header of all OPCUA request messages.

The default is: 1001

RequestHeaderReturnDiagnostics integer

-returndiagnostics integer Use this property to specify thevendor-specific diagnostics that theserver is to return in the responseheader. The value represents a bitmask of 32 bits. Refer to thevendor documentation for thevalues this property can take.

The default is: 64.




RequestHeaderTimeoutHint integer

-timeouthint integer Use this property to specify thetimeout period (in milliseconds)for all HTTP requests sent to theOPC UA server. A value of 0indicates that there is no timeoutin force. The value of this propertyis used for the timeoutHintparameter of the Request Headerin all SOAP service requests.

The default is: 0.

ResyncInterval integer -resyncinterval integer Use this property to specify thetime (in seconds) between eachresynchronization operation. Avalue of 0 means that the probenever resynchronizes with thetarget system.

The default is: 60.

RetryCount integer -retrycount integer Use this property to specify themaximum number of times theprobe tries to reconnect to thetarget system following acommunications failure. Ifreconnection does not occur afterthis number of attempts, the probeshuts down. A value of 0 meansthat the probe does not try toreconnect to the target but simplyshuts down.

The default is: 0.

RetryInterval integer -retryinterval integer Use the property to specify thetime (in seconds) between eachattempt to reconnect to the targetsystem.

A value of 0 means that the probeuses an exponentially increasingperiod between successiveconnection attempts. For example,the probe waits 1 second, then 2seconds, then 4 seconds, and soon.

The default is: 0.




StreamCapture integer -streamcapture (This isequivalent toStreamCapture with avalue of true (1).)

-nostreamcapture (This isequivalent toStreamCapture with avalue of false (0).)

Use this property to specifywhether the stream capture featureis enabled. The property takes thefollowing values:

1: The probe uses the streamcapture feature.

0: The probe does not use thestream capture feature.

The default is: 0.Note: If you set the value of thisproperty to 1, define a value forthe StreamCaptureFilePathproperty as well.

StreamCaptureFilePathstring

-streamcapturefilepathstring

Use this property to specify thedirectory where the probe storesthe input data stream.

The default is: "".

See “Data stream capture” on page18 for more information on how touse this property.

TrustStore string -truststore string Use this property to specify the filename (with full path) of thetruststore file that contains thetrusted certificates.

The default is: "".

TrustStorePassword string

-truststorepassword string Use this property to specify thepassword required to access thetruststore file containing thetrusted certificates.

The default is: "".

TrustStoreType string -truststoretype string Use this property to specify thetruststore type obtained from thetruststore, for example: JKS,PKCS12, and so forth.

The default is: JKS.


ElementsThe probe breaks event data down into tokens and parses them into elements.Elements are used to assign values to ObjectServer fields; the field values containthe event details in a form that the ObjectServer understands.

The following table describes the elements that the probe generates. Not all theelements described are generated for each event; the elements that the probegenerates depends upon the event type.

Table 12. Elements

Element name Element description

$ClientHandle This element contains the user-supplied identifierfor a monitored item. “<RequestedParameters>”on page 48 describes the client handle and itsuse.

$EventId This element contains the identifier of the eventwhich is the subject of an event notification.

$EventType This element identifies the type of event which isthe subject of an event notification.

$InnerStatusCode This element contains the status code returnedfrom the underlying system used to complete theexecution of an OPC UA service.

$MessageText This element contains the message text associatedwith an event notification.

$NodeId This element identifies the node in the servernamespace where a data change has occurred.

$OpcUaEventType This element identifies the type of OPC UA eventthat has occurred. This element can have thefollowing values:

DataChangeNotification

EventNotificationList

StatusChangeNotification

$Severity This element contains the severity code associatedwith an event notification. The code is a numberbetween 1 and 1000. The higher the number themore severe the event.

$SourceName This element contains the name of the node inthe server namespace that generated an eventnotification.

$SourceNode This element contains the identifier of the node inthe server namespace that generated an eventnotification.


Table 12. Elements (continued)

Element name Element description

$SourceTimestamp This element contains the Coordinated UniversalTime (UTC) that identifies when a change in adata value occurred at the source. The time isexpressed as the number of 100 nanosecondintervals since 1 January 1601.

$StatusCode This element contains the new status code thattriggered the occurrence of a status changenotification.

$Time This element contains the time when an eventnotification occurred.

$Value This element contains the value of the dataelement that is the subject of a data changenotification.

Error messagesError messages provide information about problems that occur while running theprobe. You can use the information that they contain to resolve such problems.

The following table describes the error messages specific to this probe. Forinformation about generic error messages, see the IBM Tivoli Netcool/OMNIbusProbe and Gateway Guide.

Table 13. Error messages

Error Description Action

Exception duringmarshallingnotification messageto element: cause

An exception occurred while the probewas parsing incoming events. The causecontains a message associated with theexception.

Contact IBM Support.

Run the probe in debugand stream capturemode to collect theprobe debug log andstream capture log andsubmit the logs to IBMsupport.

Exception increatingEventNotificationList event: cause

An exception occurred while the probewas creating an ObjectServer event inresponse to receiving an eventnotification from the OPC UA server.The cause contains a message associatedwith the exception.




Table 13. Error messages (continued)


Exception in parsingnotification event:cause

An exception occurred while the probewas parsing data in an eventnotification received from the OPC UAserver. The cause contains a messageassociated with the exception.



Exception increating DataChangeNotification event:cause

An exception occurred while the probewas creating an ObjectServer event inresponse to receiving a data changenotification from the OPC UA server.The cause contains a message associatedwith the exception.



Exception in parsingDataChange event:cause

An exception occurred while the probewas parsing data in a data changenotification received from the OPC UAserver. The cause contains a messageassociated with the exception.



Exception increating StateChangeNotification event:cause

An exception occurred while the probewas creating an ObjectServer event inresponse to receiving notification of astate change in a monitored item. Thecause contains a message associated withthe exception.



Exception in parsingStateChange event:cause

An exception occurred while the probewas parsing data in a state changenotification received from the OPC UAserver. The cause contains a messageassociated with the exception.






Unknown event type:type with id:identifier

The probe received a notification fromthe OPC UA server that is not one ofthe types that the probe recognizes. Thatis, the notification does not indicate adata change, event notification, or astatus change. The type shows the typeof the notification and identifier is itsidentifier.

Currently, the probe onlysupports a few eventtypes identified in theOPC UA standard. If theprobe receives anunknown event type,contact IBM support. Itcould be that either theprobe is unable torecognize the event typeor the event type is notsupported.

ServiceExceptionduring setting upproperties forendpoint...

A ServiceException has occurred whilethe probe was reading the propertiesrequired to set up communication withthe OPC UA server.


Unable to connect asclient to endpoint:cause

An exception occurred during theprocess of connecting to the OPC UAserver, creating a session and activatingthat session. The cause contains amessage associated with the exception.

Make sure that the OPCUA server is up andrunning and check theconnection relatedproperties such as host,port, and service name.Ensure that there is nofirewall issue blockingthe connection. If theproblem continues,contact IBM support.

Timeout whilewaiting responsefrom OPC-UA, waitfor next resynccycle.

When the probe issues a Publish requestto the OPC UA server, it expects aresponse within a set time period. Thiswarning indicates that there was noresponse. This can occur for any of thefollowing reasons:

v There are no notifications on theserver to send to the probe.

In this case, the server queues thepublish request and sendsnotifications when any are available.In addition the probe tries again atthe next publishing interval.

v There is an error in the connectionbetween the probe and the server.

v The server is incorrectly configured.

The probe will retryagain in the nextresynchronize cycle.




MalformedURLException duringcreate URL for WSDLlocation: cause

The URL of the WSDL file for the SOAPsession is incorrectly formatted. Thecause contains more information on thenature of the error. Either the value ofthe EndpointWsdlLocation property isincorrect or, if that property has novalue, one or more of the followingproperties have incorrect values:

EndpointHttpHost

EndpointHttpPort

EndpointSessionServiceName

Check that the value ofeach of the propertieshas the correct syntax,and that the values arecorrect for your site.Correct any errors andrestart the probe.

Unable to createsession.

The probe was unable to create thesession with the OPC UA serverthrough the OPC UA CreateSessionservice.

The values of one ormore of the followingproperties are incorrector invalid:

HttpTimeout


OPCSessionName

RequestedSessionTimeout

Ensure that all theseproperties have valuesthat are valid for yoursite and then restart theprobe.

Unable to activatesession identifiers:sessionid

The probe was unable to activate theOPC UA session. The sessionid containsthe identifier of the session.

It is a very rare case thatthe OPC UA serverreturns a session ID thatthe probe cannotactivate. It could be oneof the following hasoccurred:

v The activate sessionhas expired.

v The OPC UA serverhas removed theactivate session.

v The OPC UA server isno longer responsiveor alive.

Ensure that the OPC UAserver is running. Then,stop the probe and retrythe connection to theOPC UA server.

If the problem continues,contact IBM support.




Unable createmonitored items.

The probe was unable to send the list ofitems to be monitored to the OPC UAhost as part of theCreateMonitoredItems service.

Check that thedefinitions of themonitored items in theOpcUaEvent.xml orOpcUaDataChange.xmlconfiguration files andany notification filtersyou have defined arevalid. Correct any errorsand restart the probe.

Unable createsubscription.

The probe was unable to create asubscription for monitored itemsbecause the OPC UA CreateSubscriptionservice failed.

The values of one ormore of the followingproperties are incorrector invalid:

MaxNotificationPerPublish

RequestedLifetimeCount

RequestedMaxKeepAliveCount

RequestedPublishingInterval

Ensure that all theseproperties have valuesthat are valid for yoursite and then restart theprobe.

Unable to publishand get alarms fromendpoint.

A Publish operation failed to completesuccessfully.

Check that the OPC UAserver is operating andhas connectivity to theprobe. In addition checkthat the followingproperties have valuesthat are correct andvalid:

HttpTimeout


There is some errorsoccurred duringpublish request:

The OPC UA Publish service returnedone or more errors. The lines in the logfile immediately following this messagedescribe the publishing errors.

For each error, locate itscause and amend theconfiguration of theprobe, the server, or bothas appropriate.

SOAP Handlerexception foroutbound message:cause

An exception occurred when the probewas manipulating the header of anoutbound SOAP message. The causecontains a message associated with theexception.





SOAPException duringstream capturelogging: cause

A SOAP exception occurred when theprobe was capturing the stream ofSOAP data to a file. The cause contains amessage associated with the exception.

Check the followingproperties and ensurethat the configurationinside theopc_ua_dsl_log.properties file is correct:

v StreamCapture

v StreamCapturePath

v DSLLogConfig

If the problem continues,contact IBM support.

IOException duringstream capturelogging: cause

An I/O error occurred when the probewas capturing the stream of SOAP datato a file. The cause contains a messageassociated with the error.

This exception is rare,but when it occurs it istypically caused by theenvironment or machineissues related to the I/Ooperation not being ableto open and write intothe log file.

Check to ensure that themachine is stable andhealthy (for example,sufficient disk space).

Exception duringstream capturelogging: cause

An error, other than a SOAP exceptionor an I/O error, occurred when theprobe was capturing the stream ofSOAP data to a file. The cause contains amessage associated with the error.

Contact IBM supportand provide theexception cause anddetails.

IOException whenclosing streamcapture buffer:cause

An I/O error occurred when the probetried to close the file of captured SOAPdata. The cause contains a messageassociated with the error.

This exception is rare,but when it occurs it istypically caused by theenvironment or machineissues related to the I/Ooperation not being ableto close the buffer log.


Exception whenclosing streamcapture buffer:cause

An error, other than an I/O error,occurred when the probe tried to closethe file of captured SOAP data. Thecause contains a message associated withthe error.

This exception is rare,but when it occurs it istypically caused by theenvironment or machineissues.

Contact IBM supportand be prepared toprovide the exceptioncause and details.




Unable to createprobe watch.

An error occurred when the probe triedto create and send a ProbeWatchmessage to the ObjectServer.

Check that theObjectServer is up andrunning and that theprobe server is in goodhealth (for example,there is sufficient CPUmemory and disk space).

It is possible that theerrors are caused by theTivoliNetcool/OMNIbus Corelibrary, nonnative, orprobe SDK Java. If thisis the case, contact IBMsupport.

Unable to find theconfiguration filedefined by theMonitoredItemsConfigFile property:cause

The probe was unable to find the XMLfile that defines the set of items tomonitor. The path of this file is in theMonitoredItemsConfigFile property. Thecause contains a message associated withthe error.

Make sure that the valueof the MonitoredItemsConfigFile property iscorrect and has thecorrect syntax. Ensurethat the probe can openand read the file. Followany advice given theaccompanying errormessage.

The returned statuscode Statusindicates that someissues may haveoccurred whencreating themonitored items onthe server.

The status code returned from the OPCUA CreateMonitoredItem service is nota success code. Status contains the statuscode that the OPC UA server returned.

Refer to the OPC UAspecification or the OPCUA server (vendor)documentation to verifythe cause of the statuscode and possible waysto correct the issue.

Unable to close thebuffer reader -IOException: cause

The probe encountered an IO exceptionwhen it tried to close the bufferedreader that receives notifications. Thecause contains a message associated withthe error.

This exception is rare,but when it occurs it istypically caused by theenvironment or machineissues related to the I/Ooperation not being ableto close the buffer log.


The probe onlysupports aconfiguration filethat has no morethan CharCountcharacters.

The probe limits the size of the XML filethat defines the items to monitor toCharCount characters. The file you havesupplied exceeds that limit.

Reduce the size of thefile by means such as:

v Reducing or removingcomments

v Reducing the amountof white space

v Removing somedefinitions ofmonitored items




Could not find therelated attributelist for the clienthandle handle. Theprobe will use thedefault attributelist for the event.

The probe should generate the eventattribute list for the client handlespecified for the <ClientHandle></ClientHandle> tag in the XMLconfiguration file associated with theMonitoredItemsConfigFile property.However, the probe could not find theevent attribute list for this client handle.Thus, the probe will use the defaultevent attribute list.

Ensure that you havespecified a valid eventattribute list in the XMLconfiguration fileassociated with theMonitoredItemsConfigFile property (thedefault is$OMNIHOME/var/OpcUaEvent.xml).

Ensure that you specifya unique client handle inthe <ClientHandle></ClientHandle> tag foreach of the event setsyou want to monitor. Aclient handle is aninteger and you can startwith the values 1, 2, 3,and so forth. Thus, ifthere were three eventsets that you want tofollow you wouldspecify the following:

<ClientHandle>1</ClientHandle>...<ClientHandle>2</ClientHandle>...<ClientHandle>3</ClientHandle>...

For each client handle,ensure that you define avalid set of eventattributes within the<SimpleAttributeOperand></SimpleAttributeOperand> tags containedwithin the<SelectClauses></SelectClauses> tags.




Duplicate clienthandle key found.The client handlealready exists inthe currentattribute map.

The probe found a duplicate clienthandle where that client handle alreadyexisted in current event attribute map.

Ensure that you havespecified a unique clienthandle in the XMLconfiguration fileassociated with theMonitoredItemsConfigFile property (thedefault is$OMNIHOME/var/OpcUaEvent.xml). For theevent notification list,you can share the clienthandle only if you areusing the same set ofevent attributes (definedwithin the<SelectClauses></SelectClauses> tags forall the monitored events.Otherwise, you shouldspecify a unique clienthandle(<ClientHandle></ClientHandle> tags) foreach set of monitoredevents.

If you are sharing theclient handle correctly asspecified previously,ignore this warningmessage.

Some errors occurredwhile the probe wascreating monitoreditems.

The probe returned a nonzero statuscode after attempting to create themonitored event attribute list. Thenonzero value indicates that some errorsoccurred.

Check the log files andthe XML configurationfile associated with theMonitoredItemsConfigFile property (thedefault is$OMNIHOME/var/OpcUaEvent.xml) toensure that themonitored event itemsconfiguration is correct.


ProbeWatch messagesDuring normal operations, the probe generates ProbeWatch messages and sendsthem to the ObjectServer. These messages tell the ObjectServer how the probe isrunning.

The following table describes the raw ProbeWatch messages that the probegenerates. For information about generic ProbeWatch messages, see the IBM TivoliNetcool/OMNIbus Probe and Gateway Guide.

Table 14. ProbeWatch messages

ProbeWatch message Description Triggers/causes

Exception duringmarshalling notificationmessage in parser thatmay cause event loss!

An exception occurred whilethe probe was creating anObjectserver event from anincoming notification. Thiscan cause loss of events in theprobe.

This message can be causedby an error in any of theservices that the probe uses tocreate the ObjectServer event.

To obtain more informationabout this occurrence, enabledata stream capture. Thisenables you to get a detailedview of the information theprobe receives from the OPCUA server. See “Data streamcapture” on page 18.

Exception during addingnotification message intoqueue and may causingevent loss.

An exception occurred whilethe probe was adding anincoming notification to thequeue of messages awaitingprocessing into ObjectServerevents. This can cause eventloss in the probe.

This message can be causedby an error in any of theservices that the probe uses toqueue incoming notificationmessages.

To obtain more informationabout this occurrence, refer tothe DSL Log file(opc_ua_dsl.log in$NCHOME/omnibus/probes, bydefault).

Unable to parse theincomingDataChangeNotification.

An exception occurred whilethe probe was processing adata change notification.

This message can be causedby an error in any of theservices that the probe uses toparse data changenotifications.



Table 14. ProbeWatch messages (continued)

ProbeWatch message Description Triggers/causes

Unable to parse theincomingEventListNotification.

An exception occurred whilethe probe was processing anevent list notification.

This message can be causedby any of the services that theprobe uses to parse event listnotifications.


Unable to parse theincomingStateChangeNotification.

An exception occurred whilethe probe was processing astate change notification.

This message can be causedby any of the services that theprobe uses to parse statechange notifications.


Unable to create eventsin object server. An exception occurred while

the probe was adding anevent to a queue ready fortransmission to theObjectServer. This can causeevent loss in the probe.


START SYNCHRONIZATIONThe probe has begun ascheduled resynchronizationwith the OPC UA server.

This is normal behavior basedon the values of theInitialResync andResyncInterval properties.

END SYNCHRONIZATIONA scheduledresynchronization with theOPC UA server is complete.

The synchronization operationhas completed normally.



Chapter 2. The XML configuration files for event and datachange notifications

The IBM Tivoli Netcool/OMNIbus Probe for OPC Unified Architecture (UA) isdelivered with the following XML configuration files that allow you to defineevent and data change items on the OPC UA server that you want the probe tomonitor:v OPCUaEvent.xml

v OPCUaDataChange.xml

If you want to subscribe to event notification only, customize the OPCUaEvent.xmlconfiguration file. If you want to subscribe to data change notification only,customize the OPCUaDataChange.xml configuration file.

Note: Although it is possible to subscribe to both event notification and datachange notification in the same XML configuration file (that is, eitherOPCUaEvent.xml or OPCUaDataChange.xml), the customizing the XML configurationfile instructions explain how to customize OPCUaEvent.xml andOPCUaDataChange.xml separately.

The XML configuration files reside in the $OMNIHOME/var directory.

The following topics define the structure and content of the OPCUaEvent.xml andOPCUaDataChange.xml configuration files:v “Structure of the XML configuration files” on page 46v “<ListOfMonitoredItemCreateRequest>” on page 47v “<MonitoredItemCreateRequest>” on page 47v “<DataChangeFilter>” on page 49v “<EventFilter>” on page 50

The following topic provides instructions on how to customize the OPCUaEvent.xmland OPCUaDataChange.xml configuration files:v “Customizing the XML configuration files” on page 52

Use the MonitoredItemsConfigFile property to specify the full path of the XMLconfiguration file that contains information on the items that the probe is tomonitor. The information in this file is used in the OPC UA CreateMonitoredItemsservice. You can specify OPCUaEvent.xml, OPCUaDataChange.xml, or a file name ofyour choice.


Structure of the XML configuration filesUse this information to understand the structure of the XML configuration filesdelivered with the IBM Tivoli Netcool/OMNIbus Probe for OPC UnifiedArchitecture (UA).

The XML declaration

The XML configuration files are XML documents that contain an XML declarationfollowed by the <ListOfMonitoredItemCreateRequest> root element.

The document begins with the XML declaration. In this release of the probe, thisdeclaration is:<?xml version="1.0" encoding="UTF8" standalone="yes">

The <ListOfMonitoredItemCreateRequest> root element

The root element holds the document's content and defines the default namespace.In this release of the probe, the syntax of the root element is:<ListOfMonitoredItemCreateRequestxmlns="http://opcfoundation.org/UA/2008/02/Types.xsd">...</ListOfMonitoredItemCreateRequest>

Content of the root element

The root element contains one or more <MonitoredItemCreateRequest> and</MonitoredItemCreateRequest> elements. Each of these elements defines an itemin the OPC UA server that the probe wants monitored and what the probe wantsto be notified of for that item. You can set up the following types of notification forany monitored item:v Data changev Event

Order of Elements

Unless otherwise specified the elements in the XML document appear in the ordershown in this definition.

Case sensitivity

In XML documents, element and attribute names are case sensitive. Use the samecase as specified in this definition. In addition, the content of some elements is alsocase sensitive. The description of individual elements includes information on casesensitivity, if any.

Content restrictions

There are restrictions on the content of some elements. For example, there may bea limit on the number of characters they can contain, or the content may berestricted to a defined set of values. The description of elements in this definitionsets out any content restrictions.


Comments

You can include comments in the configuration files using the standard XMLsyntax. For example:

Example configuration files

The probe provides two example XML configuration files:OpcUaEvent.xml: Contains definitions of subscriptions to events.OpcUaDataChange.xml: Contains definition of subscriptions of changes to data.

You can find both files in the $OMNIHOME/var directory.

Note: You need to manually configure this property to the actual path withoutusing the $OMNIHOME or $NCHOME environment variables.

<ListOfMonitoredItemCreateRequest>The <ListOfMonitoredItemCreateRequest> and</ListOfMonitoredItemCreateRequest> elements contain a single request to createone or more items to monitor. The items to monitor are either events or datachanges.

The <ListOfMonitoredItemCreateRequest> and</ListOfMonitoredItemCreateRequest> elements contain one or more<MonitoredItemCreateRequest> and </MonitoredItemCreateRequest> elements.

<MonitoredItemCreateRequest>The <MonitoredItemCreateRequest> and </MonitoredItemCreateRequest> elementsdefine an item that you want the OPC UA server to monitor and returnnotifications to the Probe for OPC UA when requested. A notification can indicatea change in the data associated with the monitored item, or the occurrence of anevent.

The <MonitoredItemCreateRequest> and </MonitoredItemCreateRequest> elementscontain the following child elements:

<ItemToMonitor></ItemToMonitor>

Specify an item to monitor. See “<ItemToMonitor>” on page48.

<MonitoringMode></MonitoringMode>

Specify the type of monitoring to carry out on the item. Inthis release of the probe, use the value of Reporting_2.

<RequestedParameters></RequestedParameters>

Specify the parameters that define the type of monitoringthat the probe requires. See “<RequestedParameters>” onpage 48.

Chapter 2. The XML configuration files for event and data change notifications 47

<ItemToMonitor>The <ItemToMonitor> and </ItemToMonitor> elements define an element in theOPC UA server's address space that the probe wants to be monitored.

The <ItemToMonitor> and </ItemToMonitor> elements contain the following childelements:

<NodeId> </NodeId> Specify the unique identifier of the node in the OPC UAserver's address space.

<AttributeId></AttributeId>

Specify the data type of the attribute within the node thatthe OPC UA server is to monitor.

The OPC UA standard defines the values for node identifiers and data typeattributes.

<RequestedParameters>The <RequestedParameters> and </RequestedParameters> elements define thedetails of what is to be monitored and how.

The <RequestedParameters> and </RequestedParameters> elements contain thefollowing child elements:

<ClientHandle></ClientHandle>

Specify a unique identifier for this monitored item. Theidentifier is an integer. The probe uses this value to matchnotifications with the appropriate node.

<SamplingInterval></SamplingInterval>

Specify the frequency, in milliseconds, that the OPC UAserver is to sample the monitored item. The following listdescribes the valid values:

0: Indicates that the server is to use the fastest practicalrate for sampling the monitored item.

-1: Indicates that the server is to use the defaultsampling interval that was defined during the creation ofthe Subscription. The RequestedPublishingIntervalproperty contains this default sampling interval.

Note: if you provide a negative number for the content ofthis element, the probe treats it as being -1.

<Filter> </Filter> Specify an optional filter to use to determine when themonitored item generates a notification. See “<Filter>” onpage 49.

<QueueSize> </QueueSize> Specify the requested size of the queue to hold notificationsfrom the monitored item. Notifications remain in the queueuntil sent to the probe in response to a Publish request.

The values 0 and 1 have special meaning, depending on thetype of notification that is generated. For data changenotifications, 1 and 0 cause the server to use the defaultqueue size of one. For event notifications, 0 causes theserver to use the default queue entry. A value of 1 causesthe OPC UA server to use the minimum queue size.


<DiscardOldest></DiscardOldest>

Specify the policy that the OPC UA server is to followshould the queue of notifications become full. The followinglist describes the valid values:

false: The OPC UA server discards notifications that aregenerated after the queue becomes full.

true: The OPC UA server discards the oldest notificationin the queue to make way for each new notification thatarrives.

<Filter>The <Filter> and </Filter> elements are optional and define a filter thatdetermines when the monitored item generates a notification.

The <Filter> </Filter> element pair contain the following child elements:

<TypeId> </TypeId> Identify the type of filter and contains a single child elementpair: <Identifer> and </Identifer>. The <Identifer> and</Identifer> elements contain an identifier for the type offilter, and can be one of the following values:

i=723: Use this value for a data change filter.

i=726: Use this value for an event filter.<Body> </Body> Contain the body of the filter that defines the conditions for

generating a notification. The <Body> </Body> elementscontain one of the following child elements:

v For data change items: <DataChangeFilter> and</DataChangeFilter>. The OPCUaDataChange.xmlconfiguration file delivered with the probe providesexamples of these elements.

v For event items: <EventFilter> and </EventFilter>. TheOPCUaEvent.xml configuration file delivered with theprobe provides examples of these elements.

For more information, see:

“<DataChangeFilter>”

“<EventFilter>” on page 50

<DataChangeFilter>The <DataChangeFilter> and </DataChangeFilter> elements define the conditionswhere the change in the monitored item's value causes the server to generate adata change notification.

The <DataChangeFilter> and </DataChangeFilter> elements contain the followingchild elements:


<Trigger> </Trigger> Identify the conditions under which the server creates a datachange notification. The following list describes the validvalues:

Status_0: Generate a notification only when the statuscode associated with the value changes.

StatusValue_1: Generate a notification when either thevalue or its associated status code changes. You can use adeadband filter, defined in the <DeadbandType> and</DeadbandValue> elements, to provide additionalfiltering of value changes.

StatusValueTimestamp_2: Generate a notification whenthe value, its associated status code, or its sourcetimestamp change. If you specify a deadband filter, thistrigger operates in the same way as StatusValue_1.

If there is no filter associated with a monitored item, thedefault trigger is StatusValue_1.

<DeadbandType></DeadbandType>

Define the type of the deadband and is one of the followingvalues:

0: There is no deadband filter associated with this value.

1: The filter is an absolute value.

2: The filter is a percentage.<DeadBandValue></DeadBandValue>

Determine when a notification resulting from a change in anitem's value is generated.

When <DeadbandType> and </DeadbandType> contain 1, thiselement contains the absolute change in the item's datavalue that causes the generation of a notification. Forexample, if this element contains the value 100, the servergenerates a notification if the item's value changes by 10 ormore units.

When <DeadbandType> contains 2, this element contains thepercentage change in the item's range of data values thatcauses the generation of the notification. For example, if theitem has a total value range of 250 and the value of thiselement is 10, the server generates a notification if the item'svalue changes by 25 or more units.

<EventFilter>The <EventFilter> </EventFilter> elements define which events associated with amonitored item result in the server generating a notification.

The <EventFilter> and </EventFilter> elements contain the following childelements:

<SelectClauses></SelectClauses>

Contain one or more <SimpleAttributeOperand> and</SimpleAttributeOperand> elements, each of which definesthe values to include in a notification. See“<SimpleAttributeOperand>” on page 51.

<WhereClauses></WhereClauses> Contain the <Elements> and </Elements> elements which in

turn contain the <ContentFilterElement> and</ContentFilterElement> elements. That element limits theevents that can cause the generation of a notification tothose that meet conditions that the element's contentsdefine. See “<ContentFilterElement>” on page 51.


<SimpleAttributeOperand>The <SimpleAttributeOperand> and </SimpleAttributeOperand> elements define avalue to include in each notification that the OPC UA server generates for thismonitored item. This value is an attribute of the monitored item.

The <SimpleAttributeOperand> and </SimpleAttributeOperand> elements containthe following child elements:

<TypeDefinitionId></TypeDefinitionId>

Define the type of the attribute. For example, a value ofi=2041 indicates that this is a base event type.

<BrowsePath> </BrowsePath> Specify the relative path to the node. This element containsone <QualifiedName> and </QualifiedName> element pairthat define the path. See “<QualifiedName>.”

<AttributeId></AttributeId>

Specify the identifier of the attribute to include in anotification. The OPC UA standard defines the attributeidentifiers. For example, a value of 13 selects the value of anitem.

Note: The value 13 indicates a string data type.

<QualifiedName>The <QualifiedName> and </QualifiedName> elements contain the relative path tothe node as a qualified name.

The <QualifiedName> and </QualifiedName> elements contain the following childelements:

<NamespaceIndex></NamespaceIndex>

Specify an index for the namespace URI that includes thenode. Use a value of 0 for the node identifiers defined in theOPC UA standard.

<Name> </Name> Specify the name of the node.

<ContentFilterElement>The <ContentFilterElement> and </ContentFilterElement> elements defineconditions that limit the events that can cause the server to generate a notification.

The <ContentFilterElement> and </ContentFilterElement> elements contain thefollowing child elements:

<FilterOperator></FilterOperator>

Specify the operator to use in the filter. This determines thenumber of operands required.

<FilterOperands></FilterOperands>

Specify the definition of an operand for the expressiondefined by the operator. The type of operator defines thenumber of operands required. For example, the NOToperator requires one operand only, whereas the Equalsoperator requires two operands.

This element can contain an <ExtensionObject> element. See“<ExtensionObject>” on page 52.


<ExtensionObject>The <ExtensionObject> and </ExtensionObject> elements define an applicationspecific data type that may not be recognized by the receiver.

Customizing the XML configuration filesUse this information to customize the mandatory and optional XML elements inthe OPCUaEvent.xml and OPCUaDataChange.xml configuration files to accommodateyour environment.

Before you begin

Before you customize the OPCUaEvent.xml and OPCUaDataChange.xml configurationfiles, consider the following guidelines:v The IBM Tivoli Netcool/OMNIbus Probe for OPC Unified Architecture (UA)

delivers with two XML configuration files: OPCUaEvent.xml andOPCUaDataChange.xml. If you want to subscribe to event notification only,customize the OPCUaEvent.xml configuration file. If you want to subscribe to datachange notification only, customize the OPCUaDataChange.xml configuration file.

Note: Although it is possible to subscribe to both event notification and datachange notification in the same XML configuration file (that is, eitherOPCUaEvent.xml or OPCUaDataChange.xml), these instructions explain how tocustomize the OPCUaEvent.xml and OPCUaDataChange.xml configuration filesseparately.

v The XML configuration files reside in the $OMNIHOME/var directory.v There must be at least one monitored event or data item request in the

OPCUaEvent.xml and OPCUaDataChange.xml configuration files. You specify each ofthese requests using the <MonitoredItemCreateRequest></MonitoredItemCreateRequest> element pair. You can add or remove eventnotification or data change notification requests by adding or removing<MonitoredItemCreateRequest> </MonitoredItemCreateRequest> element pairs.

v The <ClientHandle></ClientHandle> element specifies a unique client handle(represented by integers, for example, 1, 2, 3, and so forth) for each monitoredevent notification or data change notification.

v You must customize the filter for the $OpcUaEventType element. This elementidentifies the type of OPC UA event that has occurred. The specific value youwant to filter on is EventNotificationList.For more information on the $OpcUaEventType element (and other elements), see“Elements” on page 32.

v You must use the MonitoredItemsConfigFile property to specify the full path ofthe XML configuration file that contains information on the items that the probeis to monitor. The information in this file is used in the OPC UACreateMonitoredItems service.The default value is: $OMNIHOME/var/OpcUaEvent.xml.

Customizing the OPCUaEvent.xml configuration file

To customize the OPCUaEvent.xml configuration file for event notification, do thefollowing:1. Go to the directory in which the OPCUaEvent.xml configuration file resides. For

example:cd $OMNIHOME/var


2. Copy the OPCUaEvent.xml configuration file to a backup file. For example:cp OPCUaEvent.xml OPCUaEvent.xml.save

This ensures that if you make any mistakes you can access the originalOPCUaEvent.xml configuration file.

3. Using an appropriate editor, open the OPCUaEvent.xml configuration file forediting.

4. Locate the <NodeId> element's <Identifier> and </Identifier> elements andspecify the unique identifiers of the node in the OPC UA server's addressspace that you want to monitor. The following example shows the values thatcome with the OPCUaEvent.xml configuration file delivered with the probe:<MonitoredItemCreateRequest>

<ItemToMonitor><NodeId>

.

.

.<Identifier>ns=5;s=Well_24412</Identifier></NodeId>

.

.

.</ItemToMonitor>

.

.

.</MonitoredItemCreateRequest>...<MonitoredItemCreateRequest>


.

.

.<Identifier>ns=5;s=Well_48306</Identifier></NodeId>

.

.

.</ItemToMonitor>

.

.

.</MonitoredItemCreateRequest>...

5. Locate the <AttributeId> and </AttributeId> elements and specify theattribute identifiers for event notification. It is recommended that you specifythe value 12 (which represents the String data type) for event notification orcheck with the OPC UA information model for additional guidance onpossible values. The following example shows the values that come with theOPCUaEvent.xml configuration file delivered with the probe:<MonitoredItemCreateRequest>

<ItemToMonitor>...

<AttributeId>12</AttributeId>..


.</ItemToMonitor>

.

.


<ItemToMonitor>...

<AttributeId>12</AttributeId>...

</ItemToMonitor>...</MonitoredItemCreateRequest>...

6. Locate the <MonitoringMode> and </MonitoringMode> elements and ensure thatthe values specified are Reporting_2 so that the Probe for OPC UA probe canreceive events from the OPC UA server. The following example shows thevalues that come with the OPCUaEvent.xml configuration file delivered withthe probe:<MonitoredItemCreateRequest>

<ItemToMonitor>...

</ItemToMonitor>...<MonitoringMode>Reporting_2</MonitoringMode></MonitoredItemCreateRequest>...<MonitoredItemCreateRequest>

<ItemToMonitor>...

</ItemToMonitor>...<MonitoringMode>Reporting_2</MonitoringMode></MonitoredItemCreateRequest>...

7. Locate the <ClientHandle> and </ClientHandle> elements and ensure that youspecify a unique client handle (an integer value starting with 1) for each eventnotification item you want to monitor. The OPCUaEvent.xml configuration filecomes with two event item requests (specified with the


<MonitoredItemCreateRequest> and </MonitoredItemCreateRequest> elements)and thus defines two client handles as follows:<MonitoredItemCreateRequest>...<ClientHandle>1</ClientHandle>...</MonitoredItemCreateRequest>

<MonitoredItemCreateRequest>...<ClientHandle>2</ClientHandle>...</MonitoredItemCreateRequest>...

8. Locate the <SamplingInterval> and </SamplingInterval> elements and specifyan appropriate value to instruct the OPC UA server on the frequency withwhich it publishes events into the queue. The following example shows thevalues that come with the OPCUaEvent.xml configuration file delivered withthe probe:<MonitoredItemCreateRequest>...<ClientHandle>1</ClientHandle>

<SamplingInterval>1</SamplingInterval>...</MonitoredItemCreateRequest>...<MonitoredItemCreateRequest>...<ClientHandle>2</ClientHandle><SamplingInterval>0.0</SamplingInterval>...</MonitoredItemCreateRequest>...

9. Ensure that the <EventFilter> and </EventFilter> elements are included.These elements contain the <SelectClauses> and </SelectClauses> elementswhich are also mandatory.The <SelectClauses> and </SelectClauses> elements contain the eventattributes you want to receive from the OPC UA server. In the OPCUaEvent.xml


configuration file delivered with the probe the default event attributes arecontained within the <SimpleAttributeOperand> and</SimpleAttributeOperand> elements.The <SimpleAttributeOperand> and </SimpleAttributeOperand> elementsdelivered with the OPCUaEvent.xml configuration file contain the followingdefault event attributes:v EventIdv EventTypev SourceNodev SourceNamev Timev ReceiveTimev LocalTimev Severityv Message

10. You can modify any of the default event attributes specified within a<SimpleAttributeOperand> </SimpleAttributeOperand> element pair. You canalso add event attributes by adding <SimpleAttributeOperand></SimpleAttributeOperand> element pairs and by adding the followingelements within those pairs:v <TypeDefinitionId> </TypeDefinitionId>

v <Identifier> </Identifier>

v <BrowsePath> </BrowsePath>

v <QualitifedName> </QualifiedName>

v <NamespaceIndex> </NamespaceIndex>

v <Name> </Name>

v <AttributeId> </AttributeId>

You can also delete event attributes by deleting one or more<SimpleAttributeOperand> and </SimpleAttributeOperand> element pairs andthe associated elements that they contain.The following example shows the EventId attribute entry delivered with theOPCUaEvent.xml configuration file:...<EventFilter>

<SelectClauses><SimpleAttributeOperand><TypeDefinitionId><Identifier>i=2041</Identifier></TypeDefinitionId><BrowsePath><QualifiedName><NamespaceIndex>0</NamespaceIndex><Name>EventId</Name></QualifiedName></BrowsePath><AttributeId>13</Attribute></SimpleAttributeOperand>

.

.

.


11. Modify the elements contained within the <WhereClause> and </WhereClause>and <Elements> and </Elements> element pairs to accommodate the needs ofyour environment. See the OPC UA specification for information aboutcustomizing the where clause filter for event filtering.

12. Modify the <QueueSize> and </QueueSize> and <DiscardOldest> and</DiscardOldest> element pairs to accommodate the needs of yourenvironment. The following example shows the default values that come withthe OPCUaEvent.xml configuration file delivered with the probe:<MonitoredItemCreateRequest>...<ClientHandle>1</ClientHandle>...<QueueSize>1000</QueueSize><DiscardOldest>true</DiscardOldest>...</MonitoredItemCreateRequest>...<MonitoredItemCreateRequest>...<ClientHandle>2</ClientHandle>...<QueueSize>1000</QueueSize><DiscardOldest>true</DiscardOldest></MonitoredItemCreateRequest>...

13. Save the OPCUaEvent.xml configuration file with the modifications you havemade.

14. Edit the MonitoredItemsConfigFile property to specify the full path of theXML configuration file, in this example OpcUaEvent.xml. For example:MonitoredItemsConfigFile: "/opt/tivoli/netcool/omnibus/var/OpcUaEvent.xml"

15. Start the probe to run and check the probe logs to ensure the monitored eventitems are created successfully. For example:Status code 0 indicate the monitored items are createdsuccessfully without issues.2014-07-03T15:33:03: Debug: D-JPR-000-000:CreatedMonitoredItems 1 Item Id: 14 , status code:02014-07-03T15:33:03: Debug: D-JPR-000-000:CreatedMonitoredItems 2 Item Id: 15 , status code:0

Customizing the OPCUaDataChange.xml configuration file

To customize the OPCUaDataChange.xml configuration file for data changenotification, do the following:1. Go to the directory in which the OPCUaDataChange.xml configuration file

resides. For example:cd $OMNIHOME/var


2. Copy the OPCUaDataChange.xml configuration file to a backup file. Forexample:cp OPCUaDataChange.xml OPCUaDataChange.xml.save

This ensures that if you make any mistakes you can access the originalOPCUaDataChange.xml configuration file.

3. Using an appropriate editor, open the OPCUaEvent.xml configuration file forediting.

4. Locate the <NodeId> element's <Identifier> and </Identifier> elements andspecify the unique identifiers of the node in the OPC UA server's addressspace that you want to monitor. The following example shows the values thatcome with the OPCUaDataChange.xml configuration file delivered with theprobe:<MonitoredItemCreateRequest>


.

.

.<Identifier>ns=2;s=1:Pipe2001?Online/FalseState</Identifier></NodeId>

.

.

.</ItemToMonitor>

.

.



.

.

.<Identifier>ns=2;s=1:FC1001?Status/EnumStrings</Identifier></NodeId>

.

.

.</ItemToMonitor>

.

.



.

.

.<Identifier>ns=2;s=1:Pipe2001?Measurement/EURange</Identifier></NodeId>

.

.

.</ItemToMonitor>

.


.


5. Locate the <AttributeId> and </AttributeId> elements and specify theattribute identifiers for event notification. It is recommended that you specifythe value 12 (which represents the String data type) for event notification orcheck with the OPC UA information model for additional guidance onpossible values. The following example shows the values that come with theOPCUaDataChange.xml configuration file delivered with the probe:<MonitoredItemCreateRequest>

<ItemToMonitor>...


</ItemToMonitor>...</MonitoredItemCreateRequest>...<MonitoredItemCreateRequest>

<ItemToMonitor>...


</ItemToMonitor>...</MonitoredItemCreateRequest>...

<MonitoredItemCreateRequest><ItemToMonitor>

.

.

.<AttributeId>13</AttributeId>

.

.

.</ItemToMonitor>

.

.



6. Locate the <MonitoringMode> and </MonitoringMode> elements and ensure thatthe values specified are Reporting_2 so that the Probe for OPC UA probe canreceive events from the OPC UA server. The following example shows thevalues that come with the OPCUaDataChange.xml configuration file deliveredwith the probe:<MonitoredItemCreateRequest>

<ItemToMonitor>...


<ItemToMonitor>...


<ItemToMonitor>...

</ItemToMonitor>...<MonitoringMode>Reporting_2</MonitoringMode></MonitoredItemCreateRequest>...

7. Locate the <ClientHandle> and </ClientHandle> elements and ensure that youspecify a unique client handle (an integer value starting with 1) for each datachange notification item you want to monitor. The OPCUaDataChange.xmlconfiguration file comes with three data change item requests (specified withthe <MonitoredItemCreateRequest> and </MonitoredItemCreateRequest>elements) and thus defines three client handles as follows:<MonitoredItemCreateRequest>...<ClientHandle>1</ClientHandle>...</MonitoredItemCreateRequest>

<MonitoredItemCreateRequest>


.

.

.<ClientHandle>2</ClientHandle>...</MonitoredItemCreateRequest>...<MonitoredItemCreateRequest>...<ClientHandle>3</ClientHandle>...

8. Locate the <SamplingInterval> and </SamplingInterval> elements and specifyan appropriate value to instruct the OPC UA server on the frequency withwhich it publishes events into the queue. The following example shows thevalues that come with the OPCUaDataChange.xml configuration file deliveredwith the probe:<MonitoredItemCreateRequest>...<ClientHandle>1</ClientHandle>

<SamplingInterval>1</SamplingInterval>...</MonitoredItemCreateRequest>...<MonitoredItemCreateRequest>...<ClientHandle>2</ClientHandle><SamplingInterval>0</SamplingInterval>...</MonitoredItemCreateRequest>...<MonitoredItemCreateRequest>...<ClientHandle>3</ClientHandle><SamplingInterval>0</SamplingInterval>...</MonitoredItemCreateRequest>

9. Customize the data change filter (specified by the <Filter> and </Filter>elements) or the aggregate filter for data change notification according to the


needs of your environment. For more information on customizing the datachange filter and the aggregate filter, see the OPC UA specification.The following example shows the data change filter elements that the<Filter> </Filter> elements contain. The example also shows placeholdersfor adding your data change filters. These come with the OPCUaDataChange.xmlconfiguration file delivered with the probe:<MonitoredItemCreateRequest>...

<ClientHandle>1</ClientHandle>...

<Filter><TypeId><Identifier>i=723</Identifier></TypeId><Body><Trigger>StatusValue_1</Trigger><DeadbandType>0</DeadbandType><DeadbandValue>0</DeadbandValue></DataChangeFilter></Body></Filter>

.

.

.</MonitoredItemCreateRequest>...<MonitoredItemCreateRequest>...<ClientHandle>2</ClientHandle>...

<Filter />...</MonitoredItemCreateRequest>...<MonitoredItemCreateRequest>...<ClientHandle>3</ClientHandle>..


.

<Filter />...</MonitoredItemCreateRequest>...

10. Modify the <QueueSize> and </QueueSize> and <DiscardOldest> and</DiscardOldest> elements to accommodate the needs of your environment.The following example shows the default values that come with theOPCUaDataChange.xml configuration file delivered with the probe:<MonitoredItemCreateRequest>...<ClientHandle>1</ClientHandle>...<QueueSize>1000</QueueSize><DiscardOldest>true</DiscardOldest>...</MonitoredItemCreateRequest>...<MonitoredItemCreateRequest>...<ClientHandle>2</ClientHandle>...<QueueSize>10</QueueSize><DiscardOldest>true</DiscardOldest>...</MonitoredItemCreateRequest>...<MonitoredItemCreateRequest>...<ClientHandle>3</ClientHandle>...<QueueSize>10</QueueSize><DiscardOldest>true</DiscardOldest>...</MonitoredItemCreateRequest>...


11. Save the OPCUaDataChange.xml configuration file with the modifications youhave made.

12. Edit the MonitoredItemsConfigFile property to specify the full path of theXML configuration file, in this example OpcUaDataChange.xml. For example:MonitoredItemsConfigFile: "/opt/tivoli/netcool/omnibus/var/OpcUaDataChange.xml"

13. Start the probe to run and check the probe logs to ensure the monitored datachange items are created successfully. For example:Status code 0 indicate the monitored items are createdsuccessfully without issues.2014-07-03T15:33:03: Debug: D-JPR-000-000:CreatedMonitoredItems 1 Item Id: 14 , status code:02014-07-03T15:33:03: Debug: D-JPR-000-000:CreatedMonitoredItems 2 Item Id: 15 , status code:0


Appendix. Notices and Trademarks

This appendix contains the following sections:v Noticesv Trademarks

NoticesThis information was developed for products and services offered in the U.S.A.

IBM may not offer the products, services, or features discussed in this document inother countries. Consult your local IBM representative for information on theproducts and services currently available in your area. Any reference to an IBMproduct, program, or service is not intended to state or imply that only that IBMproduct, program, or service may be used. Any functionally equivalent product,program, or service that does not infringe any IBM intellectual property right maybe used instead. However, it is the user's responsibility to evaluate and verify theoperation of any non-IBM product, program, or service.

IBM may have patents or pending patent applications covering subject matterdescribed in this document. The furnishing of this document does not grant youany license to these patents. You can send license inquiries, in writing, to:

IBM Director of LicensingIBM CorporationNorth Castle DriveArmonk, NY 10504-1785U.S.A.

For license inquiries regarding double-byte (DBCS) information, contact the IBMIntellectual Property Department in your country or send inquiries, in writing, to:

IBM World Trade Asia CorporationLicensing 2-31 Roppongi 3-chome, Minato-kuTokyo 106-0032, Japan

The following paragraph does not apply to the United Kingdom or any othercountry where such provisions are inconsistent with local law:INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THISPUBLICATION “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHEREXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIEDWARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESSFOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express orimplied warranties in certain transactions, therefore, this statement may not applyto you.

This information could include technical inaccuracies or typographical errors.Changes are periodically made to the information herein; these changes will beincorporated in new editions of the publication. IBM may make improvementsand/or changes in the product(s) and/or the program(s) described in thispublication at any time without notice.


Any references in this information to non-IBM Web sites are provided forconvenience only and do not in any manner serve as an endorsement of those Websites. The materials at those Web sites are not part of the materials for this IBMproduct and use of those Web sites is at your own risk.

IBM may use or distribute any of the information you supply in any way itbelieves appropriate without incurring any obligation to you.

Licensees of this program who want to have information about it for the purposeof enabling: (i) the exchange of information between independently createdprograms and other programs (including this one) and (ii) the mutual use of theinformation which has been exchanged, should contact:

IBM CorporationSoftware Interoperability Coordinator, Department 49XA3605 Highway 52 NRochester, MN 55901U.S.A.

Such information may be available, subject to appropriate terms and conditions,including in some cases, payment of a fee.

The licensed program described in this information and all licensed materialavailable for it are provided by IBM under terms of the IBM Customer Agreement,IBM International Program License Agreement, or any equivalent agreementbetween us.

Any performance data contained herein was determined in a controlledenvironment. Therefore, the results obtained in other operating environments mayvary significantly. Some measurements may have been made on development-levelsystems and there is no guarantee that these measurements will be the same ongenerally available systems. Furthermore, some measurements may have beenestimated through extrapolation. Actual results may vary. Users of this documentshould verify the applicable data for their specific environment.

Information concerning non-IBM products was obtained from the suppliers ofthose products, their published announcements or other publicly available sources.IBM has not tested those products and cannot confirm the accuracy ofperformance, compatibility or any other claims related to non-IBM products.Questions on the capabilities of non-IBM products should be addressed to thesuppliers of those products.

All statements regarding IBM's future direction or intent are subject to change orwithdrawal without notice, and represent goals and objectives only.

All IBM prices shown are IBM's suggested retail prices, are current and are subjectto change without notice. Dealer prices may vary.

This information is for planning purposes only. The information herein is subject tochange before the products described become available.

This information contains examples of data and reports used in daily businessoperations. To illustrate them as completely as possible, the examples include thenames of individuals, companies, brands, and products. All of these names arefictitious and any similarity to the names and addresses used by an actual businessenterprise is entirely coincidental.


COPYRIGHT LICENSE:

This information contains sample application programs in source language, whichillustrate programming techniques on various operating platforms. You may copy,modify, and distribute these sample programs in any form without payment toIBM, for the purposes of developing, using, marketing or distributing applicationprograms conforming to the application programming interface for the operatingplatform for which the sample programs are written. These examples have notbeen thoroughly tested under all conditions. IBM, therefore, cannot guarantee orimply reliability, serviceability, or function of these programs.

Each copy or any portion of these sample programs or any derivative work, mustinclude a copyright notice as follows:

© (your company name) (year). Portions of this code are derived from IBM Corp.Sample Programs. © Copyright IBM Corp. _enter the year or years_. All rightsreserved.

If you are viewing this information softcopy, the photographs and colorillustrations may not appear.

TrademarksIBM, the IBM logo, ibm.com, AIX, Tivoli, zSeries, and Netcool are trademarks ofInternational Business Machines Corporation in the United States, other countries,or both.

Adobe, Acrobat, Portable Document Format (PDF), PostScript, and all Adobe-basedtrademarks are either registered trademarks or trademarks of Adobe SystemsIncorporated in the United States, other countries, or both.

Intel, Intel Inside (logos), MMX, and Pentium are trademarks of Intel Corporationin the United States, other countries, or both.

Microsoft, Windows, Windows NT, and the Windows logo are trademarks ofMicrosoft Corporation in the United States, other countries, or both.

Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in theUnited States, other countries, or both.

Linux is a trademark of Linus Torvalds in the United States, other countries, orboth.

UNIX is a registered trademark of The Open Group in the United States and othercountries.

Appendix. Notices and Trademarks 67


��

Printed in USA

SC27-6552-00

IBM Tivoli Netcool/OMNIbus Probe for OPC Unified ... · For probes supported only on Windows operating systems, ... HP-UX Integrity-based systems ... 2 IBM Tivoli Netcool/OMNIbus

Documents