智联海Modbus写入应答成功，为什么不能当成设备动作完成
Modbus功能码16的正常响应包含功能码、起始地址与写入数量。它不是原始写值的完整回显，也没有替应用定义物理动作完成条件，业务接口需要补充设备约定的状态证据。
记录请求与响应对应关系
保存设备、功能码、起始地址、数量和原始写值，核对响应范围。响应正常说明的边界需要明确，不应把没有返回全部数据的响应描述成设备已逐项回显并确认了所有业务语义。
先记录交付设备、软件与配置版本，再确认本节所述能力是否由该组合实际提供。把未支持、未启用和未验证分别记录；其他机型的演示不能代替当前交付对象的证据。
区分寄存器值与设备采纳
按设备接口说明判断是否需要读回、提交或状态确认。读回相同也可能只是存储值相同，不自动证明控制逻辑已采用该参数，应说明当前模式和生效条件。
验证时保留原始输入和判断依据，避免只交付一张成功截图。每一轮只改变已约定的变量，记录变化前后的配置与结果；未覆盖的边界条件需要明确列出，不能自动计入通过范围。
明确物理完成的证据
若写入触发动作，另行定义设备完成状态、应用身份与允许期限。不能用协议往返结束作为动作完成时刻，也不能通过实际危险动作验证通信；应采用经批准的隔离观察方式。
将图中三种现象作为讨论起点，而不是对现场故障的预先诊断。先核对记录是否完整、单位和身份是否一致，再决定需要补充哪项观察。若证据不足，应保留待确认结论，而不是用经验值填补缺失字段。
处理超时后的不确定状态
写请求发出后未收到响应，不能简单认定未执行，也不应盲目重发可能重复触发的命令。依据设备的身份、状态或幂等约定消除不确定性，并把无法确认的情况保留为待处理状态。
由现场负责人确定获准的隔离验证方式，分别记录正常、异常和恢复阶段。验证重点是系统如何识别和解释不可信输入，不应为了取得异常样本而让实际生产设备执行未经评估的动作。
交付分层成功条件
把协议正常、参数正确、设备采纳和业务完成分别列为结果。样本记录每层依据及异常分支，更新设备逻辑或客户端重试策略后复核，避免最终界面只有一个无法解释的成功提示。
交付时附上配置、样本、结果表和未决问题，并约定后续变更的复核责任。接收方应能随机挑选一条结论，回到对应输入与判断过程；若做不到，这份报告仍需要补充可追溯资料。