两台设备抬一件货：交叉作业要协调的是路径和时序
一、协同的难点不是一个算法，是三类约束
有一条消息值得从软件角度读：据公开报道，一项围绕起重机机群智能协同作业的关键技术获得行业科技奖项，公开描述的技术路径是先在施工现场的三维场景里关联设备位置、作业状态与空间关系，再按任务与工序衔接统筹分配，协调多设备交叉作业的路径与动作时序，并做主动防碰撞；适配轮式、塔式、履带等多种机型，支撑多机交叉作业与双机联合抬吊，已应用于若干大型工程基地。获奖含金量、厂商能力与任何载荷参数都不在本篇讨论范围。要看的只有一件事：这类系统在解什么类型的问题。
我们的读法是，它解的不是“一个调度算法”，而是三类彼此不同的约束。第一类是几何干涉：两台设备的臂架、吊物与回转范围在同一片空间里会不会重叠。第二类是时序窗口：动作的先后与并行是否允许，一方的动作会把另一方挡在门外多久。第三类是工序依赖导致的资源长期占用：某台设备占住通道或作业面，是因为它在做一件必须完成的前置工作，而不是因为它在移动。三类约束的可观测数据不同、判据不同、误判的代价也不同。把它们压进一个统一模型里，是这类项目最常见的失败方式：系统看起来什么都在算，实际上任何一类误报都归不了因。
还有一点要先说明：协同系统改变的是“冲突能不能被提前看见”，它不把风险变成零。任何把这套系统描述成消除问题的方案，都是把工程问题转成了信任问题。
二、现场数字化的最小信息集
三类约束都建立在同一份现场数据之上，而这份数据的每一项都要有归属：谁采集、多久一次、精度要求多少。我们列的最小信息集有六项。
设备身份与姿态：位置、朝向、臂架或作业部件的展开状态。姿态比位置更难采，因为它常常依赖附加传感器或者由机械角度反算，反算的假设要在文档里写明。作业状态：待机、移动、加载中、锁定，状态的定义要和现场操作员的用语一致，不能由软件自己发明一套。吊物与回转范围：物件外形与悬吊后的摆动空间，这一项决定了几何干涉的边界是否可信。人员与临时障碍：人、临时堆料、夜间新增的围挡，这是最容易过期的一类数据。风与视野这类约束量：影响动作允许条件的环境量，要有来源和更新频率。最后是数据质量本身：每条记录的采集时间、新鲜度与置信说明，没有它，后面所有判据都无法解释。
这六项里最常被省掉的是新鲜度。位置数据晚两秒，在慢速设备上无所谓，在交叉作业的动作重叠段里就是判据失效。系统要把“多旧的数据还可以参与判定”写成显式配置，并在超期时改为保守行为，而不是继续用旧值算下去。
三、从“位置可见”到“冲突可预判”的三层
只做第一层，系统是个定位看板：能看到都在哪，不能预判会不会撞上。第二层是几何干涉检查，把每台设备的作业包络建成可计算的体积，检查两两是否重叠以及未来的重叠趋势。第三层是时序：把动作计划放到同一条时间轴上，检查在什么区间里两个计划会同时要求同一片空间或同一个资源。第四层要再加一层工序依赖：有些占用是长时且合法的，冲突的表现不是重叠，而是一方等不到自己的窗口。
这三层的误判代价不对称，所以阈值不能共用一套。几何层误报的代价是让整组动作停下来，影响的是进度；几何层漏报的代价直接落在安全上。时序层的误报代价小得多，通常只是让某台设备空等一个窗口；漏报则会演变成动作冲突。因此每一层要有独立的阈值与独立的告警等级：几何层宁可保守，触发即停；时序层可以灵敏，给操作员提前量而不是硬拦。把所有告警合成一个等级、配一个阈值，最后一定被现场关掉——这是这类系统最常见的实际死法，不是被技术否定的。
四、核心交付物：三类约束、判据与误判处置
| 约束类型 | 可验收判据 | 需要的数据与频率 | 误判（漏判）处置 | 误判（误报）处置 |
|---|---|---|---|---|
| 几何干涉 | 包络重叠检查在给定位置误差下不出现漏检；预测窗口可配置 | 姿态与位置高频上报，误差与新鲜度随记录带出 | 立即停，双方动作锁定，人工确认后才恢复 | 分级提示并记录，超一定频次进入阈值复核 |
| 时序窗口 | 同一片空间的占用计划在时间轴上互不重叠，切换有安全间隔 | 动作计划、状态变更事件 | 提前一个窗口提示，由操作员决定 | 允许排队等待，不打断当前动作 |
| 工序依赖 | 长时占用被显式登记，不被当成异常冲突反复告警 | 工序表、资源占用登记 | 排入等待序列并给出预计释放时间 | 占用超期告警，转人工核查 |
| 动作同步 | 双机抬吊时同步误差在容忍带内，越带即触发共同中止 | 双方姿态与受力侧的状态量 | 整体中止，任一方降级都停止作业 | 收敛提示，允许一次微调 |
| 环境约束 | 达到约束量上限时禁止特定动作并留原因 | 环境与视野数据及其来源 | 禁止动作而不是给建议 | 记录为可解释的保守决策 |
| 数据缺失 | 传感器失效或数据超期时进入降级模式 | 每条链路的健康状态 | 收缩为人工指挥并要求确认留痕 | 降级期间的告警单独归档便于复盘 |
五、双机抬吊把责任问题摆到台面上
单机作业时“谁下指令”这个问题被隐式解决了。两台设备共担一件物件时，四个问题必须显式回答。
动作同步误差的容忍带要写成数值区带，并说明越带之后的动作是什么：先提示、再减速还是直接共同中止。这条带子由现场工艺与设备能力共同确定，不能由软件单方面定。任一方降级即整体中止：一侧失去定位、失去数据或者机构报警时，另一侧不允许继续完成动作。这类互锁要在系统层实现，而不是靠规程写在纸上。指令由谁下达要留痕：协同作业期间的指令、确认与中止要有对应的人和时刻，事后能重建时序；谁有权发出中止、谁有权解除锁定，要在权限里区分清楚。最后，双机共担物件的可读性要求比单机高：界面上要用一句话说明“现在谁在等谁”，而不是让操作员自己从坐标里推。
主动防碰撞的可验证性是另一个容易落空的点。要验收的是四件事：触发条件是否可解释（哪两个对象、什么距离、什么时间窗）；延迟预算是否被核算过（从感知到执行机构动作之间有多少时间被系统消耗，包括通信、计算与机构响应）；传感器失效时的降级策略是否明确（失效后是收缩作业范围还是转人工指挥，不允许出现“没有依据但照常作业”）；事件记录是否可复盘（每条告警保留判据输入，而不是只保留结果）。这四条构成了我们对这类功能的验收清单，缺一条就不能算验证过。
六、机型分档、软件侧交付清单与可迁移的场景
异构机型不能共用一套规则，原因是运动学和作业包络不同：塔式的固定回转与高范围、履带的大回转与地面承载限制、轮式的可移动性与支腿作业面，三者的“危险接近”定义都不一样。规则要按机型分档，并让每台设备匹配到正确的档位，档位错配比没有规则更糟。
软件侧的交付清单不长，但每一条都是硬前提：数据接入协议与各字段含义；坐标基准与时间基准的统一（不同来源的坐标不在同一参考系、时钟没有对齐，是所有几何与时序判据的地基）；冲突告警的处置流程，包括谁确认、多久确认、确认后系统恢复什么状态；以及现场人员能读懂的提示语，避免用系统内部术语下指令。
这套结构并不只属于吊装场景。工厂里叉车与人员混行的通道与路口，是几何与时序的叠加；仓库里自动搬运设备与门、电梯、充电桩之间的互斥，是典型的工序依赖占用；园区多工位共用一条通道时，冲突不是重叠而是谁也拿不到窗口。三个场景都能复用上面那张表的列，只是判据的数据来源不同。
洹拓科技在客户现场做这类系统时，一般会把第一步定为“把三类约束分别写成一页判据”，而不是先建三维场景。场景是好东西，但它会让所有人误以为看见了就等于管住了。协调的实质是路径和时序，判据分开写清楚，才谈得上验收。