QtOpcUa应用中OpcUa BadTimeout报错原因排查咨询

我有一个基于QtOpcUa开发的Qt应用，仅配置了若干订阅，未执行轮询、浏览等其他操作。每过几分钟就会收到服务器返回的BadTimeout错误并断开连接，且该问题仅在启用订阅且同时连接多个PLC时出现。根据文档，BadTimeout表示操作超时，但订阅由服务器维护，想明确该超时的成因，是服务器端问题还是客户端可通过优化解决？

错误日志 #

[20231003 12:51:19 I] unknown:0 - "Received a ServiceFault response"
[20231003 12:51:19 I] unknown:0 - "The ServiceResult has the StatusCode BadTimeout"
[20231003 12:51:19 W] unknown:0 - "Received Timeout for Publish Response"

成因分析与优化方向 #

服务器端可能的原因 #

• 资源过载：同时处理多个客户端的订阅请求时，PLC服务器的CPU、内存或网络带宽不足，无法及时响应Publish请求，触发超时。
• 配置限制：PLC的OPC UA服务器可能设置了过短的Publish请求超时阈值，或者对并发订阅数、会话数有严格限制，达到上限后无法正常处理请求。
• 订阅维护异常：服务器在维护订阅状态时出现逻辑错误，未能按时向客户端发送Publish响应，导致客户端判定超时。

客户端可优化的措施 #

• 调整订阅参数：检查QOpcUaSubscription的publishingInterval、lifetimeCount、maxKeepAliveCount等参数，确保与服务器配置匹配。若服务器处理较慢，适当调大lifetimeCount和maxKeepAliveCount，避免因响应延迟被判定超时。
• 优化订阅策略：不要一次性创建大量订阅，分批次初始化以降低服务器瞬间负载；合并同一PLC内的节点订阅，减少通信频次。
• 网络与超时配置：确保客户端与各PLC的网络稳定，避免丢包或高延迟。可增大QOpcUaClient::setTimeout的值，给服务器更长的响应窗口。
• 会话管理优化：为每个PLC创建独立会话，避免单会话承载过多订阅引发资源竞争；监听会话状态，超时断开时自动重连并恢复订阅。

内容的提问来源于stack exchange，提问作者Mark