平台横倾异常发生在火箭下降末段。


    控制系统检测到右舷浪涌，命令左侧压载舱排水、右侧进水。理论上十六只阀应按分配曲线同步动作，实际横倾却先朝相反方向增加。


    两秒后，姿态才被拉回。对普通船舶而言两秒很短，对正准备落下的火箭而言，两秒足以让制导系统多做一轮侧向修正。


    火箭飞控日志显示，那次额外修正消耗的推进剂不多，却把支腿预期落点向左推了二十七厘米。安全裕度被同时从平台与火箭两端吃掉，只看任何一边都不会觉得严重。


    平台惯导、阀位和火箭相对位置原本使用三套时钟。团队先把它们统一到同一时间基准，才确认甲板反向倾斜发生在阀门实际动作之前，而不是数据对不齐造成的假顺序。


    事后单阀测试中，十六只阀的开启时间都在限值内。液压泵输出稳定，阀芯也没有海水腐蚀卡滞。


    周野要求重放毫秒级日志。普通监控只每秒记一次位置，看上去所有阀同时到位；高速控制记录里，右侧第四阀比左侧第七阀晚了五十二毫秒。


    五十二毫秒本身不至于造成零点四度横倾，问题在于控制器看到初始姿态没改善，又追加一次修正。第一批阀还没完全动作，第二批命令已经压上去。


    液压管路中的压力波随后反射，几只阀短暂越过目标开度。平台不是没有执行命令，而是执行得太积极，先欠一步，再多走一步。


    控制团队把责任归到网络延迟。周野却发现，网络时间戳差只有七毫秒，剩下四十五毫秒发生在阀的液压响应里。


    每只阀单独动作时，蓄能器压力充足；十六只阀同时动作，远端支路瞬间降压，阀芯起步变慢。等主泵补上流量，延迟又突然消失。


    为了复现这个瞬间，液压组在台架上让十六只阀按真实动作曲线开启。只开十五只时压力谷仍不明显，第十六只加入后，瓶颈支路流速跨过临界，局部损失陡然增加。


    他们把一只近端阀与一只远端阀互换，延迟仍跟着管路位置而不是跟着阀走。十六只合格阀终于洗清了“个别动作慢”的嫌疑。


    这解释了为什么静态单阀测试全部合格，也解释了为什么海况越复杂、同时动作越多，异常越容易出现。


    林浩把管路画成网络图。四只蓄能器按平均距离布置，看似均匀，真正的同时流量路径却在右舷形成一个瓶颈弯头。


    弯头内径没有变小，内壁也干净。问题来自三条支路在同一点汇合，压力波到达后互相叠加，形成一次短暂反压。


    透明水力模型中，三股流在弯头外侧形成旋涡。旋涡只存在几十毫秒，稳态流量测试根本看不见，却刚好卡在阀芯起步阶段。


    若只把弯头换得更大，现场需要切开主干管并长时间停机。模型表明，短时本地供压能绕过旋涡最强的窗口，主泵流动稳定后再接管更经济。


    陈大川听完问：“十六只阀都没坏，合起来就会抢水？”


    梁师傅说：“一人过门都不堵，十六个人一起冲，门还是那扇门。”


    简单提高主泵压力会让近端阀动作更猛，反而扩大超调。扩大整套管径来不及，也会增加大量海上改造。


    周野提出在四个关键阀组增加本地小容量液压缓冲器。它们不承担持续供油，只负责最初几十毫秒，让远端阀先起步，再由主泵接管。


    控制策略也从“等待平台姿态变化”改为读取阀端实际位移。第一批阀没有完成规定行程前，不允许姿态控制器盲目叠加第二批命令。


    姿态信号仍参与控制，但被分成预测与校正两层。阀端位移负责告诉系统命令是否真正落地，甲板倾角负责判断水量分配是否达到效果，两者不再互相替代。


    当某组阀位与姿态变化矛盾时，系统优先进入限幅模式，不允许控制器继续加码。错误可以暂时不被完全纠正，却不能在信息不清时被放大。


    为防网络中断，每个阀组保留本地同步逻辑。收到同一动作序号后，四组先按预定曲线执行，事后再向中央控制器报告，而不是排队等逐条命令。


    系统扫描到平台仓库里一批报废起重机液压蓄能器。壳体耐压足够，因接口标准不匹配被闲置，可重构成紧凑缓冲组件。


    【检测到可重构液压储能组件】


    【目标：阀组本地缓冲与同步闭环控制】


    【预计消耗重构点：】


    【当前重构点：】


    周野没有确认。蓄能器若释放太快，会把延迟问题变成冲击问题；释放太慢，又赶不上最关键的五十二毫秒。


    缓冲器还必须面对海上温度变化。液压油低温黏度增加，节流响应会变慢；甲板被太阳晒热后，蓄能器预充压力又会上升。八十毫秒窗口不能只在实验室室温成立。


    团队把台架放入温控舱，从低温清晨到高温甲板分别测试。结果显示单一孔口无法兼顾全温区，必须让两级节流随压差被动切换，而不能依靠一条固定软件参数。


    系统必须在浪涌真的到来前先准备好那一口压力，却不能让十六只阀像被人从背后同时踹开。