This Service is implemented by Discovery Servers.

This Serviceregisters a Serverwith a Discovery Server. This Servicewill be called by a Serveror a separate configuration utility. Clientswill not use this Service.

A Servershall establish a SecureChannelwith the Discovery Serverbefore calling this Service. The SecureChannelis described in 5.5. The Administratorof the Servershall provide the Serverwith an EndpointDescriptionfor the Discovery Server as part of the configuration process. Discovery Serversshall reject registrations if the serverUriprovided does not match the applicationUriin Server Certificateused to create the SecureChannel.

This Servicecan only be invoked via SecureChannelsthat support Clientauthentication (i.e. HTTPS cannot be used to call this Service).

A Serveronly provides its serverUriand the URLs of the DiscoveryEndpointsto the Discovery Server. Clientsshall use the GetEndpoints Serviceto fetch the most up to date configuration information directly from the Server.

The Servershall provide a localized name for itself in all locales that it supports.

Serversshall be able to register themselves with a Discovery Serverrunning on the same machine. The exact mechanisms depend on the Discovery Serverimplementation and are described in OPC 10000-6.

There are two types of Serverapplications: those which are manually launched including a start by the operating system at boot and those that are automatically launched when a Clientattempts to connect. The registration process that a Servershall use depends on which category it falls into.

The registration process for manually launched Serversis illustrated in Figure 11.


Figure 11– The Registration Process – Manually Launched Servers

The registration process for automatically launched Serversis illustrated in Figure 12.


Figure 12– The Registration Process – Automatically Launched Servers

The registration process is designed to be platform independent, robust and able to minimize problems created by configuration errors. For that reason, Serversshall register themselves more than once.

Under normal conditions, manually launched Serversshall periodically register with the Discovery Serveras long as they are able to receive connections from Clients. If a Servergoes offline then it shall register itself once more and indicate that it is going offline. The period of the recurring registration should be configurable; however, the maximum is 10 minutes. If an error occurs during registration (e.g. the Discovery Serveris not running) then the Servershall periodically re-attempt registration. The frequency of these attempts should start at 1 second but gradually increase until the registration frequency is the same as what it would be if no errors occurred. The recommended approach would be to double the period of each attempt until reaching the maximum.

When an automatically launched Server(or its install program) registers with the Discovery Serverit shall provide a path to a semaphore file which the Discovery Servercan use to determine if the Serverhas been uninstalled from the machine. The Discovery Server shall have read access to the file system that contains the file.

Table 6defines the parameters for the Service.

Table 6– RegisterServer Service Parameters







Common request parameters.

The authenticationTokenis always null.

The type RequestHeaderis defined in 7.33.



The Serverto register. The type RegisteredServeris defined in 7.32.




Common response parameters.

The type ResponseHeaderis defined in 7.34.

Table 7defines the Serviceresults specific to this Service. Common StatusCodesare defined in Table 182.

Table 7– RegisterServer Service Result Codes

Symbolic Id



See Table 182for the description of this result code.


See Table 182for the description of this result code.


No ServerNamewas specified.


No discovery URL was specified.


The semaphore file specified is not valid.