OPC-UA quality inspection data sync timing out during batch operations

MES Honeywell MES
, , , , , , , ,
1

We’re experiencing intermittent timeouts when syncing quality inspection data from our OPC-UA devices during batch operations. Our HM 2022.2 system connects to five quality inspection stations via OPC-UA Client G, and everything works fine during normal production. However, when batch quality checks run (typically 200-300 data points per batch), we’re seeing subscription timeouts after about 45 seconds.

The publishing interval is currently set to 1000ms, and we’re using default keep-alive settings. I’m wondering if the network MTU might be causing packet fragmentation for larger payloads, or if we need to adjust the connection pooling configuration. The timeout seems to correlate with batch sizes over 250 inspection points.

Has anyone dealt with similar OPC-UA subscription timeout issues during high-volume quality data transfers? We’re losing critical batch quality data during these timeouts, which is impacting our compliance reporting.

2

Looking at HM 2022.2 specifically with OPC-UA Client G, there are several optimizations needed for batch quality data scenarios. Let me address all the key areas:

OPC-UA Subscription Timeout Configuration: Increase your RequestedPublishingInterval to 500ms during batch operations, and set RequestedLifetimeCount to 12000 (not the default 3000). This gives subscriptions adequate time to process batch bursts without timing out.

Publishing Interval Optimization: Implement adaptive publishing intervals based on operation type. For batch quality checks, configure:

  • PublishingInterval: 500ms (reduced from 1000ms for faster data flow)
  • MaxNotificationsPerPublish: 1000 (allows larger batch chunks)
  • QueueSize: 750 (handles 300-point batches with buffer)

Connection Pooling and Keep-Alive: Your connection pool needs tuning for batch scenarios:

  • MaxSessionCount: 15 (allows concurrent batch operations)
  • MaxSubscriptionCount per session: 25
  • KeepAliveInterval: 1500ms (3x the publishing interval)
  • SecureChannelLifetime: 3600000ms (prevents channel recycling during batches)

Network MTU Validation: For batch payloads, MTU matters significantly. Run this validation:

  1. Check current MTU: netsh interface ipv4 show subinterfaces on Windows
  2. Test with large packets: `ping -f -l 8972 [inspection_device_ip]
  3. If fragmentation occurs, coordinate with network team to enable jumbo frames (MTU 9000) on the dedicated OPC-UA VLAN
  4. Update MaxMessageSize in your OPC-UA client config to 65536 bytes

Implement these changes progressively, starting with subscription parameters, then connection pooling, and finally MTU optimization if needed. This combination should eliminate your batch timeout issues while maintaining data integrity.

3

Thanks both. I checked the QueueSize and it’s set to 100, which definitely explains the buffer overflow during batches. I’ll increase it to 500 as suggested. On the MTU side, our network team confirmed we’re at standard 1500 bytes. Would enabling jumbo frames require changes on both the MES server and the inspection devices?

4

One thing often overlooked is the RequestedLifetimeCount parameter. If it’s too low, the subscription dies during batch processing delays. Set it to at least 10000 to give your subscriptions breathing room during high-volume transfers. Also check if your inspection devices support monitored item sampling intervals - you might be polling faster than necessary, creating unnecessary traffic.