2. MERLIC项目结构与误检漏检关联

在 MERLIC 的误检漏检治理中，很多问题并不是“算法不行”，而是把责任放错了层。MERLIC 由三个职责不同的组件构成：MERLIC Creator 负责离线设计与调试，MERLIC RTE（Runtime Environment）负责产线上的实时执行，MERLIC Frontend 负责操作员交互与结果呈现。误检（把良品判为 NG）和漏检（把不良品判为 OK）往往分别由不同层的配置缺陷引起，因此排查时必须先定位“问题发生在哪一层”，再决定改什么。

三个组件的职责边界

MERLIC Creator 是工程态工具。在这里完成图像源接入、工具链（Tool Chain）搭建、ROI 与参数标定、阈值设定、结果逻辑组合，并保存为可部署的 MERLIC Vision App（.mva）。Creator 里看到的“通过/不通过”是离线复算结果，它决定了检测能力的上限。

MERLIC RTE 是运行态引擎。它加载 .mva，按触发信号执行工具链，把图像处理结果转换为可被 PLC 消费的信号，并通过通信接口（如 OPC UA、TCP/IP、Modbus、数字 I/O）与产线交互。RTE 决定了检测能力能否稳定兑现，也决定了节拍、超时、丢帧等运行态问题。

MERLIC Frontend 是操作态界面。它显示实时图像、结果状态、统计计数，并提供配方切换、参数微调、报警确认等入口。Frontend 本身不改变算法，但它承载的配方选择、显示刷新和人工干预会直接影响“操作员看到的判定”与“实际下发的判定”是否一致。

配置层如何制造误检与漏检

Creator 中的阈值是误检漏检最直接的杠杆。以尺寸测量为例，假设标准件宽度为 20.00 mm，公差 ±0.10 mm。若把判定下限设为 19.80 mm、上限设为 20.20 mm，则公差带被放宽一倍，边缘超差件会被放行，形成漏检；反之若设为 19.95～20.05 mm，则正常波动件也会被判 NG，形成误检。正确做法是先用一批已知良品统计测量重复性（例如 σ≈0.015 mm），再按“公差边界 ± 3σ”留出测量不确定度余量，而不是凭感觉收紧或放宽。

工具链结构同样关键。若把“定位”和“测量”串成一条链，定位失败会直接导致后续测量全部失败，表现为批量误检；若把定位与测量并行、并给定位加独立的结果判断，则定位异常时能单独报警而不污染测量结果。ROI 画得过大，会把背景纹理、反光或相邻工件纳入统计，抬高噪声，导致阈值附近抖动，误检率上升；ROI 过小，则可能切掉真实缺陷区域，造成漏检。

通信与运行态的影响

RTE 与 PLC 之间的信号映射是漏检的高发区。常见错误包括：把“工具链执行完成”误当成“判定为 OK”，导致未完成判定就下发 OK；结果位取反；NG 信号只在单次触发有效而 PLC 采用电平保持读取，造成 NG 被漏读。排查时应确认三件事：结果信号在何时置位、保持多久、PLC 在哪个时刻采样。若 RTE 节拍为 80 ms 而 PLC 扫描周期为 20 ms，通常不会漏读；但若 RTE 因图像传输延迟偶发 300 ms 超时，而 PLC 在 150 ms 就采样，就会读到上一次的旧结果，形成漏检。

通信超时本身也会被误判。若 RTE 未配置超时后的默认输出，通信中断时结果位可能保持上一次的 OK，产线继续放行，这是最危险的漏检场景。工程上应把“通信心跳丢失”映射为独立的故障位，并让 PLC 在故障位有效时强制停机或走安全分支，而不是沿用旧结果。

Frontend 与配方管理

Frontend 的配方切换是批量误检的常见来源。同一台设备生产 A、B 两种型号，若操作员切换配方后未确认加载完成就启动，RTE 仍按旧配方执行，A 型号的阈值被用于 B 型号，可能整批误检或漏检。治理手段是：配方切换后由 Frontend 显示当前生效配方名与版本号，并在 RTE 侧校验配方 ID 与 PLC 下发的型号 ID 是否一致，不一致则拒绝启动并报警。

分层排查对照表