After a Clientestablishes a connection to a Serverand creates a Subscription, the Clientmonitors the connection status. Figure 36shows the steps to connect a Clientto a Serverand the general logic for reconnect handling. Not all possible error scenarios are covered.

The preferred mechanism for a Clientto monitor the connection status is through the keep-alive of the Subscription. A Clientshould subscribe for the State Variablein the ServerStatusto detect shutdown or other failure states. If no Subscriptionis created or the Serverdoes not support Subscriptions, the connection can be monitored by periodically reading the State Variable.

image039.png

Figure 36– Reconnect Sequence

When a Clientloses the connection to the Server, the goal is to reconnect without losing information. To do this the Clientshall re-establish the connection by creating a new SecureChanneland activating the Sessionwith the Service ActivateSession. This assigns the new SecureChannelto the existing Sessionand allows the Clientto reuse the Sessionand Subscriptionsin the Server. To re-establish the SecureChanneland activate the Session, the Clientshall use the same security policy, application instance certificate and the same user credential used to create the original SecureChannel. This will result in the Clientreceiving data and event Notificationswithout losing information provided the queues in the MonitoredItems do not overflow.

The Clientshall only create a new Sessionif ActivateSessionfails. TransferSubscriptionsis used to transfer the Subscriptionto the new Session. If TransferSubscriptionsfails, the Clientneeds to create a new Subscription.

When the connection is lost, Publishresponses may have been sent but not received by the Client.

After re-establishing the connection the Clientshall call Republishin a loop, starting with the next expected sequence number and incrementing the sequence number until the Serverreturns the status Bad_MessageNotAvailable. After receiving this status, the Clientshall start sending Publishrequests with the normal Publishhandling. This sequence ensures that the lost NotificationMessagesqueued in the Serverare not overwritten by new Publishresponses.

If the Clientdetects missing sequence numbers in the Publishand is not able to get the lostNotificationMessagesthrough Republish, the Clientshould use the Method ResendDataor should read the values of all data MonitoredItemsto make sure the Clienthas the latest values for all MonitoredItems.

The Server Objectprovides a Method ResendDatathat initiates resending of all data monitored items in a Subscription. This Methodis defined in OPC 10000-5. If this Methodis called, subsequent Publishresponses shall contain the current values of all data MonitoredItemsin the Subscriptionwhere the MonitoringModeis set to Reporting. If a value is queued for a data MonitoredItem, the next value in the queue is sent in the Publishresponse. If no value is queued for a data MonitoredItem, the last value sent is repeated in the Publishresponse. The Servershall verify that the Methodis called within the Sessioncontext of the Sessionthat owns the Subscription.

Independent of the detailed recovery strategy, the Clientshould make sure that it does not overwrite newer data in the Clientwith older values provided through Republish.

If the Republishreturns Bad_SubscriptionIdInvalid, then the Clientneeds to create a new Subscription.

Re-establishing the connection by creating a new SecureChannelmay be rejected, because of a new Server Application Instance Certificateor other security errors. In case of security failures, the Clientshall use the GetEndpoints Serviceto fetch the most up to date security information from the Server.

OPC 10000-6defines a reverse connect mechanism where the Serverinitiates the logical connection. All subsequent steps like creating a SecureChannelare initiated by the Client. In this scenario the Clientis only able to initiate a reconnect if the Serverinitiates a new logical connection after a connection interruption. The Clientside reconnect handling described in Figure 36applies also to the reverse connect case. A Serveris not able to actively check the connection status; therefore the Servershall initiate a new connection in a configurable interval, even if a connection to the Clientis established. This ensures that an initiated connection is available for the reconnect handling in addition to other scenarios where the Clientneeds more than one connection.