第56章 联调（1/2）

第一轮双模块联调比预期顺利。

管道调度器和参数共享引擎配对——运行四十八小时无异常。波束协同和频谱感知配对——运行四十八小时无异常。交叉配对也全部通过。

“第一轮没出问题，说明单模块的接口定义做得到位。“方泽在联调日誌上签字的时候难得露了个满意的表情。

第二轮三模块联调开始出问题了。

管道调度器、参数共享引擎、波束协同三个模块同时运行时，dsp的总线带宽出现了爭抢——三个模块同时访问片外存储器的峰值时刻，总线仲裁器来不及响应，导致参数共享引擎的环形缓衝区出现了一次读取超时。

超时只有两毫秒，但在实时系统里，两毫秒的卡顿足以让波束协同错过一次切换窗口。

左城看著日誌里那个孤零零的超时记录，沉默了十秒钟。

“总线优先级要重新分配。“他说，“波束协同的实时性要求最高，它的总线访问优先级必须排在第一。管道调度器第二，参数共享引擎第三。“

方泽改了fpga的总线仲裁逻辑，重新烧录。再跑四十八小时——没有超时。

但左城不放心，又加了一轮压力测试——模擬十五颗卫星同时在视野內的极端场景，把三个模块的负载推到设计上限的百分之一百二十。

跑了六个小时，波束协同控制器报了一次告警——分层精度切换的判断閾值在极端负载下出现了边界条件的误触发，把一颗应该用简化模型跟踪的候选星错误地提升为全精度计算，导致算力瞬间过载。

唐旭盯著告警日誌看了二十分钟，然后改了三行代码——在判断閾值上加了一个滯回区间，避免信號强度在閾值附近震盪时反覆触发精度切换。

三行代码。一个工程师可能需要三天才能定位的问题，唐旭二十分钟就找到了根因。

“波束赋形是我的地盘。“唐旭改完代码后说了句，语气平淡得像在说今天吃了什么。

第二轮联调通过。

七月中旬，第三轮全链路联调开始。

本书首发 追书认准 101 看书网，????????s.???超讚 ,提供给你无错章节，无乱序章节的阅读体验

这一轮要把402的四个模块和鼎新信息开发的终端协同接口对接起来，在同一块硬体平台上跑通完整的信號处理链路——从卫星信號接收，到频谱感知，到管道调度，到波束协同，到终端协同，全链条打通。

鼎新的技术总监带了两个工程师来402驻场联调。三个人搬著两台笔记本电脑和一箱子调试工具进了402的办公室，在角落里支了一张临时工作檯。

第一天就出了问题。

鼎新的终端协同接口发给402模块的状態数据包格式，和402这边的解析代码不匹配。

“我们按照接口规范文档v2.3开发的。“鼎新的工程师指著屏幕上的数据包结构，“状態栏位在第十六个字节开始，长度四字节。“

陈浩拿出402这边的接口代码：“我们也是按v2.3开发的。但我们的解析是从第十二个字节开始读状態栏位。“

两边的人面面相覷了三秒钟。

左城拿过接口规范文档翻到对应页面。看了三十秒后他找到了问题——v2.3版本的文档里，状態栏位的偏移量描述有一处歧义。原文写的是“偏移量12位元组（含包头）“，但包头本身的长度在不同模式下是四字节或八字节。鼎新按最大包头算偏移量十六，402按最小包头算偏移量十二。

“文档的锅。“左城把文档放下来，“不纠结谁对谁错，按实际的包头长度做动態解析——读取包头的模式栏位，再根据模式確定状態栏位的偏移量。两边都改，今天下班前改完。“