Subscription Client Basic

Use the Subscription and MonitoredItem Service Set as an efficient means to detect changes of Attribute values and / or to receive Event occurrences. Set appropriate intervals for publishing, keep alive notifications and total Subscription lifetime. Supply a sufficient number of Publish requests to the Server so that Notifications can be sent whenever a publish timer expires. Acknowledge received Notifications with subsequent Publish requests. Publish General Tests Client honors the RevisedPublishingInterval. Verify that the request is valid: The number of SubscriptionAcknowledgements matches the number of sequence numbers and Subscriptions to acknowledge. A UA Client is required to acknowledge the data from the previous Publish call (part 4, section 5.13.1.1). SubscriptionAcknowledgements is null/empty if there`s nothing to acknowledge. A valid SubscriptionId and SequenceNumber are both specified. DataChangeNotification General Tests in the Request Client checks the length of the DiagnosticInfos parameter matches the MonitoredItems parameter, if diagnostics requested. Client able to validate/process all diagnostic information, if requested. Not empty. o Lengths match the MonitoredItems length. Client checks the number of notification messages and if they exceed the MaxNotificationsPerPublish parameter the Client specified in CreateSubscription (or ModifySubscription) then the Client reports an error to the end-user and may also choose to: Process the data, if it can. o Modify or tear-down the subscription and (optionally) recreate it with a smaller MaxNotificationsPerPublish value.


Questions? Contact us
Generated: 22/11/2021 at 17:22:12 p.m.
Subscription Client Basic - 67 Test Cases
Test Case Id Test Type Keywords Test Case Description Test Requirements Expected Result

001

Lab CreateSubscription  Client creates a subscription with default parameters and adds an active monitored item (static writeable value).
Client writes this value and calls publish.
Client correctly receives and processes the response. Client logs/displays if the revised response parameters (lifetime, keepalive, notifications) differ from request parameters.
Client checks the operation of the subscription by receiving a notification for the written item.

002

Lab CreateSubscription  In a loop, Client creates a subscription each time varying the requestedPublishingInterval using the following values:
a. 3
b. 100
c. 250
d. 1000
Client checks the RevisedPublishingInterval and if it is different to the requestedPublishingInterval then it reports that the publishing interval is different to what was requested.

003

Lab CreateSubscription  In a loop, Client creates a subscription each time varying the value of requestedLifetimeCount and requestedKeepaliveCount to the following value pairs:

Requested Lifetime Count: 3
Requested Keepalive Count: 1

Requested Lifetime Count: 30
Requested Keepalive Count: 10

Requested Lifetime Count: 600
Requested Keepalive Count: 200

Requested Lifetime Count: MaxCounter
Requested Keepalive Count: MaxCounter/3

Requested Lifetime Count: 5
Requested Keepalive Count: 4
Client logs if the requested value and the revised value differ.
In the case of row `e` the client should not actually send the request to the server, but instead should either correct the figures first or reject them for further user-input (perhaps with some instructions for the end-user also).

004

Lab CreateSubscription  Client creates different subscriptions with multiple monitored items (static writeable) varying the value of MaxNotificationPerPublish to the following values:
a. 1
b. 5
c. 100
d. 1000
e. MaxCounter
Client performs an adequate number of writes to create more Notifications than MaxNotificationPerPublish and calls Publish.
Client checks the MoreNotifications parameter and calls Publish again.
Also, Client checks the number of notifications in the Publish response and logs an error if more are received than MaxNotificationPerPublish.

005

Lab CreateSubscription  Client creates a subscription with default values but publishingEnabled = false. It adds an active monitored item (static writeable), writes a value and calls publish.
The notification the client receives is a keepalive message.

006

Lab CreateSubscription  Client creates a single subscription using default parameters (except Enabled=False) monitoring a static set of Nodes.
Leave the Client for a short while, i.e. 15 seconds.
The Client issues Publish requests and processes the KeepAlive responses from the UA Server.

007

Lab CreateSubscription  Verify the client`s use of the parameters do not cause a potential loss of data, for example:
requestedPublishingInteral=100msec.
maxNotificationsPerPublish=1
requestedLifetimeCount=30.
QueueSize (monitoredItem) = 1.
If Client`s user interface or configuration allows for this, then the end-user must be notified by some form of warning or message that explains the potential for data loss.

008

Lab CreateSubscription  Client able to create 2 concurrent subscriptions with default values, except using the following values for the requestedPublishingInterval:
a) 100
b) 1000
Client checks the RevisedPublishingInterval and if it is different to the requested then it logs a message for the corresponding subscription that the publishing interval is different to what was requested.
Client logs a status of the creation (success or fail) for each subscription - if configured so.

009

Lab CreateSubscription  Client able to create 5 concurrent subscriptions with default values while varying the requestedPublishingInterval (like in test #9)
Check the priority in the request is valid/correct, particularly if the value is from user-input.

All other subscription behavior in the Client matches the tester`s expectations.

010

Lab CreateSubscription  Client able to create 10 concurrent subscriptions with default values while varying the requestedPublishingInterval (like in test #9)
Check the priority in the request is valid/correct, particularly if the value is from user-input.

All other subscription behavior in the Client matches the tester`s expectations.

011

Lab CreateSubscription  Client able to create the MAX # of concurrent subscriptions that the vendor claims to support with default values while varying the requestedPublishingInterval (like in test #9) Check the priority in the request is valid/correct, particularly if the value is from user-input.

All other subscription behavior in the Client matches the tester`s expectations.

012

Lab CreateSubscription  Client can specify a middle number as the priority for the subscription, i.e. Priority = 100.
Check the priority in the request is valid/correct, particularly if the value is from user-input.

013

Lab CreateSubscription  Client can specify a high priority to the system, i.e. Priority = 255.
Check the priority in the request is valid/correct, particularly if the value is from user-input.

014

Lab CreateSubscription  Client can use the Priority correctly to clearly establish 4 concurrent subscription priorities, such as:
1. Subscription #1, Priority = 1.
2. Subscription #2, Priority = 255.
3. Subscription #3, Priority = 100.
4. Subscription #4, Priority = 0.
Can only be checked with different priority values in multiple subscriptions under maximum load.
For the Priority = 0 subscription, the Client provides some form of warning or alert to the end-user that the associated subscription may receive data at a faster or slower frequency than expected.

015

Lab Publish  Client creates a subscription with a RequestedPublishingInterval that the server revises (e.g. 3).
Client begins Publish calls.
Client honors the RevisedPublishingInterval.
The client does not issue Publish calls faster or too much slower than the RevisedPublishingInterval.

016

Lab Publish  Client creates a subscription, adds an active MonitoredItem (static, writeable), writes to this item and calls Publish.
After receiving the first DataChange notification message the Client issues a Publish call to acknowledge the data received.
Client confirms receipt of the SubscriptionId and SequenceNumber.

017

Lab Publish  Client creates a subscription monitoring dynamic items (QueueSize = 5) with a SamplingInterval of 200ms and a RequestedPublishingInterval of 1sec.
The Client calls Publish.
The Client is expected to acknowledge the dataChange in a single call.
The Client acknowledges the subscription and SequenceNumber received in a single call to Publish.
Client processes the value changes for all monitoredItems in the dataChange, where each monitoredItem contains 1 or more value change.

018

Lab Publish  Client establishes multiple Enabled Subscriptions, each monitoring Dynamic items.
Client may invoke numerous Publish calls, one per subscription, or just one Publish call for all subscriptions.
The Client correctly processes the DataChange information for the correct Subscription.
Client acknowledges the subscriptions in one of 2 ways:
* One acknowledgement for all subscription data changes
* One acknowledgment per Publish request (if Client compartmentalizes the Publish calls per Subscription)

019

Lab Publish  Client creates multiple subscriptions providing dynamic data.
Client calls Publish numerous times.
Client processes the Publish response for the correct subscription, e.g. if Client shows values on-screen then the values change for the Nodes in the correct Subscription.

020

Publish  Client issues a Publish request.
Server responds with a DataChange notification, and also the availableSequenceNumbers collection contains 1 or more values.
Client correctly processes the DataChange.
Client issues one or more calls to Republish to obtain the available sequence numbers.

021

Publish  Client issues a Publish request.
Server responds with NO/ZERO notification messages, but the availableSequenceNumbers collection contains 1 or more values.
The client may choose to:
* acknowledge that it did receive those sequenceNumbers
* issue a Republish call for those sequenceNumbers

022

Lab Publish  Client creates an active Subscription with a RequestedPublishInterval of 5sec; MaxNotificationsPerPublish=5, monitoring a dynamic Node where QueueSize=1 and SamplingInterval=250msec.
[we expect to cause the buffer to fill]
Client calls Publish.
Upon receiving the Publish response, the Client processes any dataChange notifications.
The Client repeatedly calls Publish to get the remaining dataChange notifications for the current subscription until the MoreNotifications parameter = False.

023

Publish  Client creates a subscription and calls publish for this subscription, not acknowledging any messages.
This is an `initial` call to Publish.
Client processes the response correctly, whether it is a KeepAlive or DataChange.

024

Publish  Client creates a subscription (static writeable monitored items) and calls publish numerous times. This triggers the sending of a KeepAlive message in the server as the response for each Publish call.
Client processes the initial DataChange notification message and subsequent KeepAlive responses correctly.

025

Publish  Client creates a subscription, adds an active MonitoredItem (static, writeable), writes to this item and calls Publish.
Client calls Publish to acknowledge the data received.
In the 2nd Publish call the Client confirms receipt of the SubscriptionId and SequenceNumber received in the first Publish call and checks the results and reports any errors (none expected) to the end-user.

026

Publish  Client creates an active subscription (requestedPublishingInterval = 1000msec) with multiple dynamic items, where each item has a QueueSize of 2, and a DiscardOldest=True, and a samplingInterval of 100msec.
Call Publish.
Note: vary the intervals such to cause an overflow, based on the availability of changing Node values.
Client processes and consumes all of the dataChange values.
Client checks bit #7 of the StatusCode (overflow bit) which will = True.
Client reports that a value was lost on the server side due to a queue overflow.

027

Publish  As previous, but the MonitoredItems are configured with DiscardOldest = False.
Client processes and consumes all of the dataChange values.
Client checks bit #7 of the StatusCode (overflow bit) which will = True.
Client logs a message that a value was lost on the server side due to a queue overflow.

028

Publish  If the Client has an option to specify the number of outstanding Publish requests then use it to circumvent network latencies?
[tip: recommended option for Clients]
Once the `pipeline is loaded` then the dataChanges are being returned/consumed at the desired rate.
See UA Part 4 section 5.13.5.1 paragraph 3.

029

DataChangeNotification  Client successfully receives, validates, and processes the data no matter the contents.
Recommendation: Client processes the data as quickly as possible, i.e. does not do exhaustive operations within their event-handler.

030

DataChangeNotification  The Values within the DataChange are of each supported Scalar data-type: i.e.
Bool, Byte, Int16, Int32, Int64, UInt16, UInt32, UInt64, Float, Double, String etc.
Client is able to consume the data of each supported data-type.

031

DataChangeNotification  Array  The Values within the DataChange are of type Array and is a single dimension, for each supported data-type, i.e.
Bool[], Byte[], Int16[], Int32[], Int64[], UInt16[], UInt32[], UInt64[], Float[], Double[], String[] etc.
Client is able to consume the Array data of each supported data-type.

032

DataChangeNotification  Array  The Values within the DataChange are of type Array and are 2-dimensional, for each supported data-type, i.e.
Bool[,], Byte[,], Int16[,], Int32[,], Int64[,], UInt16[,], UInt32[,], UInt64[,], Float[,], Double[,], String[,] etc.
Client is able to consume the Array data of each supported data-type.

033

CTT DataChangeNotification  The MonitoredItems parameter contains multiple data-changes for a single MonitoredItem, i.e. one MonitoredItem changed 10 times and consequently receives 10 changes within the one event.
Note: CTT could inject values into the message stream, and with the values/timestamps being out of order.
Client processes the data accordingly, with the Client showing the `current` value correctly, determined by the Timestamp.

034

CTT DataChangeNotification  The MonitoredItems parameter contains multiple data-changes for a single
MonitoredItem, i.e. one MonitoredItem changed 10 times and consequently receives 10 changes within the one event.Also, MonitoredItems[0] OverflowBit is True
Client processes the data accordingly, with the Client showing the `current` value correctly, determined by the Timestamp.
Client reports that dataChanges for the specified MonitoredItem have been lost (dequeued) from the Server. Except if the Client has configured the MonitoredItem to over-sample.

035

CTT DataChangeNotification  Unavailable  The MonitoredItems parameter contains multiple data-changes for multiple nodes, as described in the previous test.
Summary: multiple monitoredItems have overflowBit = True.
Client processes the data accordingly, with the Client showing the `current` value correctly, determined by the Timestamp.
Client reports that dataChanges for the specified MonitoredItems have been lost (dequeued) from the Server. Except if the Client has configured these MonitoredItems to over-sample.

036

CTT DataChangeNotification  The MonitoredItems parameter contains 50 or more data-changes (in one notification message).
Note: CTT could inject values into the message stream, and with the values/timestamps being out of order.
Client processes the data accordingly (see general test #3), with the Client showing the `current` value correctly, determined by the Timestamp.

037

CTT DataChangeNotification  The MonitoredItems parameter contains 100 or more data-changes (in one notification message).
Note: CTT could inject values into the message stream, and with the values/timestamps being out of order.
Client processes the data accordingly (see general test #3), with the Client showing the `current` value correctly, determined by the Timestamp.

038

DataChangeNotification  The MonitoredItems parameter contains 500 or more data-changes (in one notification message).
Note: CTT could inject values into the message stream, and with the values/timestamps being out of order.
Client processes the data accordingly (see general test #3), with the Client showing the `current` value correctly, determined by the Timestamp.

039

DataChangeNotification  The MonitoredItems parameter contains 1,000 or more data-changes (in one notification message).
Note: CTT could inject values into the message stream, and with the values/timestamps being out of order.
Client processes the data accordingly (see general test #3), with the Client showing the `current` value correctly, determined by the Timestamp.

040

DataChangeNotification  The MonitoredItems parameter contains 5,000 or more data-changes (in one notification message).
Note: CTT could inject values into the message stream, and with the values/timestamps being out of order.
Client processes the data accordingly (see general test #3), with the Client showing the `current` value correctly, determined by the Timestamp.

041

DataChangeNotification  Diagnostics  Unavailable  The DiagnosticsInfo parameter contains valid diagnostics information for each MonitoredItem in the DataChange.
Client processes the diagnostics received.

042

Create a subscription with a PublishingInterval of 5-seconds.
Step #
Action
Expected Result(s)

1

All calls are successful.

2

Use the CTT to modify the RevisedPublishingInterval to a period much slower than the server specified and then observe the client's behavior.

Client handles the faster publish interval by observing the acknowledgements.

Err-001

CTT CreateSubscription  ServiceResult = Bad_TooManySubscriptions
Client logs and/or displays an error to the end-user.

Err-002

CTT CreateSubscription  Client creates two subscriptions where the
subscriptionId returned for the 2nd create request has the same id used previously.
Client logs and/or displays an error to the end-user. Client cannot use the subscription because it conflicts with the existing subscription of the same id.
Client prompts the end-user to disconnect from the Server and deletes its subscriptions. If the end-user rejects the disconnect request then the client warns of the potential danger of using the subscription in its conflicted state.

Err-003

CTT CreateSubscription  Inject the following RevisedPublishInterval error codes:
1.revisedPublishingInterval returned decades larger than the requestedPublishingInterval, e.g. requested*10.
2. revisedPublishingInterval returned decades smaller than the requestedPublishingInterval, e.g. requested / 10 (or a reasonable difference).
a.Client checks the revised value and if it is different to the requested then it logs a message.

b.Client logs a message that the requested and revised value differs.

Err-004

CTT CreateSubscription  Inject the following RevisedLifeTimeCount error codes:
1. revisedLifetimeCount returned decades larger than the requestedLifetimeCount, e.g. requested*10.
2. revisedLifetimeCount returned decades smaller than requestedLifetimeCount, e.g. requested / 10 (or a reasonable difference).
3. revisedLifetimeCount is less than 3 times the revisedMaxKeepAliveCount.
a.Client checks the revised value and if it is different to the requested then it logs a message.
b.Client logs a message that the requested and revised value differs.
c.Client logs and/or displays a message to the end-user.
Subscription is removed because it is not valid, i.e. revisedLifetimeCounter must be 3 times that of revisedKeepAliveCount.

Err-005

CTT CreateSubscription  Inject the following RevisedMaxKeepAliveCount error codes:
1. revisedMaxKeepAliveCount returned decades larger than the requestedMaxKeepAliveCount*10.
2. revisedMaxKeepAliveCount returned decades smaller than requestedMaxKeepAliveCount, e.g. requested / 10 (or a reasonable difference).
a.Client checks the revised value and if it is different to the requested then it logs a message.
b.Client logs a message that the requested and revised value differs.

Err-006

CTT CreateSubscription  Create an active subscription with enabled monitoredItems (mode=reporting). Client calls Publish multiple times (more than 2).
Server responds with KeepAlive messages ONLY.
Client logs an error that no dataChanges have been received. The error message is suppressed such that it is not reported upon every call to Publish, e.g. show message on every 5th Publish call.
A dataChange should`ve been received by the 2nd Publish call.

Err-007

CTT CreateSubscription  Unavailable  Client creates a subscription with publishingEnabled = False and adds an active monitoredItem (static, writeable).
Client writes this item and calls publish.
Server reports a value change in the subscription instead of a Keepalive.
Client logs and/or displays error as a value change is not expected.
Client ignores the dataChange values for the disabled subscription.

Err-008

CTT Publish  Inject the following ServiceResult error codes:
1. Bad_TooManyPublishRequests
2. Bad_NoSubscription
a.Client handles the error, logs and/or displays an error to the end-user.
Client does not issue any more Publish requests until a Publish response is received (async API).
b.Client handles the error, logs and/or displays an error to the end-user.
Client establishes a new Subscription, relinquishing any local resources.

If the Client issues an alternate call to check on the status of the subscription, e.g. SetPublishingMode, then you may need to also inject the appropriate code into that call (e.g. BadSubscriptionIdInvalid) to properly simulate a deleted subscription.

Err-009

CTT Publish  ServiceResult = Good, but the SubscriptionId is unknown to the Client.
Client handles the error, logs and/or displays an error to the end-user.
Client does NOT acknowledge the subscription or data.
Client invokes DeleteSubscription passing in this unknown SubscriptionId.

Err-010

CTT Publish  Client acknowledges any sequence number that it is not going to ask for retransmission. In any of the steps a client may also call Republish to get the NotificationMessage, but is not required to do so.
Step #
Action
Expected Result(s)

1

Inject a sequenceNumber into the availableSequenceNumbers which has been acknowledged long ago (e.g. Current sequenceNumber=99 | availableSequenceNumber=5).

Client acknowledges the injected sequenceNumber and may log the issue.

2

Inject a sequenceNumber into the availableSequenceNumbers which has been acknowledged shortly ago (e.g. Current sequenceNumber=99 | availableSequenceNumber=97).

Client acknowledges the injected sequenceNumber and may log the issue.

3

Inject a sequenceNumber into the availableSequenceNumbers which is bigger than the current sequenceNumber (e.g. Current sequenceNumber=99 | availableSequenceNumber=101).

Client acknowledges the injected sequenceNumber and may log the issue.

4

Inject a sequenceNumber into the availableSequenceNumbers which is way bigger than the current sequenceNumber (e.g. Current sequenceNumber=99 | availableSequenceNumber=200).

Client acknowledges the injected sequenceNumber and may log the issue.

Err-011

CTT Publish  Inject the following error codes:
1.NotificationMessage is empty.
2.Re-use a SequenceNumber within a new DataChange notification.

a.Client reports an error that it’s receiving invalid Publish responses.
b.Client dismisses the event.
Client reports an error that a previously acknowledged SequenceNumber has been received. Client re-acknowledges it (see clause 5.1.5 Client/Server Negotiations on page 17).

Err-012

CTT Publish  Inject the following error codes:
1.Set the PublishTime (in the NotificationMessage) to a time in the future, e.g. now + 25 hours.
2.Set the PublishTime (in the NotificationMessage) to a time in the past, e.g. now – 25 hours.
Client logs and/or displays a warning message stating that it is receiving events from the future.
Client by default should discard the data, unless the end-user selects an option to consume the data.

Err-013

CTT Publish  Inject the following error code:
ServiceResult = Good.
Clear the contents of the NotificationData parameter so that it is empty.
Enable this script to remove notifications from the response, while allowing the sequenceNumber to increment.Note: For sake of clarification, the remaining parameters (sequenceNumber and publishTime) remain present
Client initially processes the response as a Keep alive message (which is what this becomes).
Client should report the subsequent PublishResponse as problematic because the SequenceNumbers will be incrementing although there is no NotificationData.

Err-014

CTT Publish  Inject the following StatusCode:
For the first value in the Results, set the StatusCode to "Good" but StructureChanged bit = true.
Client supports structures. Clients should not process the data value unless they re-read the metadata as their parsing routines could fail because the serialized form of the data value has changed.

Err-015

CTT Publish  The response contains DataChange notifications. Set MoreNotifications to true although there are no notifications left to send.
The next Publish response will be modified (by the CTT) to be a KeepAlive message.
Client may log the misbehaving of the server but continues as normal.

Err-016

CTT Publish  The size of the results array does not match the size of SubscriptionAcknowledgements in the request. Client may log the misbehavior of the server.

Err-017

CTT Publish  Unavailable  Simulate the case where the publish response is too large for either the client or server to process and the SecureChannel goes into a fault state. Client notices the issue and recovers the connection to the server. Depending on the supported features in the server and client this may include recovering the subscription.

Err-018

CTT Publish  Inject one of the following Operation Level Results into the first and all returned item.
Step #
Action
Expected Result(s)

1

ServiceResult = Good. Results[0] = Bad_SubscriptionIdInvalid

Client logs and/or displays an error to the end-user specifying the subscription/sequenceNumber(s) that were not successfully acknowledged.

2

Results[0] = Bad_SequenceNumberUnknown

Client handles the error, and may log or display an error to the end-user.

3

ServiceResult = Good. Results[0] = Bad_ Bad_InvalidSequenceNumber

Client handles the error, and may log or display an error to the end-user.

4

ServiceResult = Good. Results[0] = Bad_SubscriptionIdInvalid Results[1] = Bad_ SequenceNumberUnknown

For the result in error Bad_InvalidSequenceNumber the Client reports an error to the end-user. For the result in error Bad_SubscriptionIdInvalid the Client may choose to handle this in a number of ways, such as establishes new Subscriptions, or disconnecting etc.

5

Results[*] = Bad_SubscriptionIdInvalid

Client logs and/or display an error to the end-user specifying the subscription/sequenceNumber(s) that were not successfully acknowledged.

Err-019

Inject the following error codes:
1.Where ‘x’ is the MaxNotificationsPerPublish from CreateSubscription
(or ModifySubscription) inject x + 1 notifications into the DataChange.
Note: MaxNotificationsPerPublish must be specified as a non-zero value for this test!
2.Where ‘x’ is the MaxNotificationsPerPublish from CreateSubscription
(or ModifySubscription) inject 10*x notifications into the DataChange.
3.Where ‘x’ is the MaxNotificationsPerPublish from CreateSubscription
(or ModifySubscription) inject 2*x notifications into the DataChange.
Client reports that more notifications were received than requested (server at fault!). If the Client can handle the response, then it processes the response normally. If the Client cannot handle the response, then the SecureChannel will be terminated and restarted. All resources will be cleanly relinquished before being recreated.

Err-020

CTT DataChangeNotification  Inject the following error codes
1.ServiceResult = Good, MonitoredItems parameter is empty but the SequenceNumber has incremented.
Client logs and/or reports the error to the end-user.
Client calls Republish to retrieve the missing SequenceNumber.

Err-021

CTT DataChangeNotification  Inject the following error codes:
1. ServiceResult = Good, the first items Timestamps are set to a date in the future, e.g. now + 1 day.
2. ServiceResult = Good, the first items StatusCode is modified to show BAD quality.
Step #
Action
Expected Result(s)

1

1.

Client logs and/or reports the error to the end-user.Client changes the StatusCode to Bad for the affected item(s).

2

2.

Client handles the bad data accordingly, and continues processing the other values.

Err-022

CTT DataChangeNotification  Inject the following error codes
1.ServiceResult = Good, all StatusCode values are made BAD.
2.ServiceResult = Bad, all StatusCode values are made GOOD.
Step #
Action
Expected Result(s)

1

1

Client handles the bad data accordingly, and continues processing the other values.

2

2

Client discards the message. Client logs and/or reports the error to the end-user.

Err-023

CTT DataChangeNotification  ServiceResult = Good, MonitoredItems parameter contains items that were not
requested or not valid, i.e. ClientHandle = ClientHandle*10.
Client logs and/or reports the error to the end-user.

Err-024

Lab DataChangeNotification  There are more MonitoredItems in the event than the Client can process based on any documented limitations, if any.
Client reports the problem to the end-user.
Client will then either:
a) Re-negotiate the subscription`s MaxNotificationsPerMessage
b) Re-establish a SecureChannel.

Err-025

CTT DataChangeNotification  The StatusChangeNotification NotificationMessage contains a StatusChangeNotification message where the StatusCode = Bad_Timeout.
Client reports the error to the end-user.
The Client relinquishes all resources for the subscription.
The Client may choose to re-establish the subscription, or simply rely on the user to manually invoke this.