1. 课程导入与MERLIC运维全景

在实验室里，MERLIC 往往只是“打开一个 .mvapp、点一下运行、看图像里有没有结果”的软件；一旦进入量产环境，它就从“视觉工具”变成了产线检测链路中的一个可靠性节点。MERLIC 的定位不是替代 PLC、机器人或 MES，而是承担“图像采集—视觉判定—结果输出”这一段职责，并把判定结果以稳定、可追溯、可复现的方式交给产线控制系统。因此，本课程讨论的运维，不是“会不会用 MERLIC”，而是“能不能让 MERLIC 在每天数千到数十万次触发中，持续给出可信结果”。

量产环境对 MERLIC 的可靠性目标可以拆成四个可度量的维度：可用性（产线计划运行时间内 MERLIC 可正常出结果的比例）、准确性（误检率与漏检率控制在工艺允许范围内）、节拍稳定性（单次检测耗时 P95 不超过工位节拍余量）、可追溯性（每次判定都能关联到图像、参数版本与时间戳）。这四个维度不是并列口号，而是互相制约：为了降低漏检而放宽阈值，可能带来误检上升；为了提升节拍而降低图像质量，可能让准确性下降。运维职责边界正是围绕这些约束划定的——工艺工程师定义“判什么、判到什么程度”，视觉运维工程师负责“怎么稳定地判出来、判不出来时怎么定位”，IT/OT 负责网络、存储与账号权限，产线电气负责触发信号与通信链路。边界不清，最常见的后果是“结果不对时所有人都在改 MERLIC 参数”，最终把可复现的配置改成了不可复现的现场状态。

从单机调试到产线部署，MERLIC 的生命周期可以概括为五个阶段：单机验证（离线图片与相机直连，确认算法可行）、工位集成（触发、通信、IO、结果字段与 PLC 对齐）、试产爬坡（小批量连续运行，收集误检/漏检与耗时分布）、量产运维（版本冻结、备份、监控、变更管理）、变更与退役（换型、换相机、换光源、软件升级与配置迁移）。很多现场问题并非出在算法本身，而是出在阶段跨越时“没有把上一阶段的假设带过去”：单机验证时用的是离线图片，工位集成时换成了真实触发，曝光与光源同步没对齐，结果就是同一套 .mvapp 在实验室通过、在产线不稳定。

下面这张图给出 MERLIC 在量产链路中的位置与运维关注点。它不描述某个具体算法，而是把“谁给 MERLIC 输入、MERLIC 输出给谁、运维在哪些点上观测和干预”一次画清楚。图中左侧是上游（触发与成像），中间是 MERLIC 内部的处理与判定，右侧是下游（PLC/机器人/MES），下方是运维观测面（日志、图像留存、参数版本、耗时统计）。

把这张图落到日常运维，最需要建立的习惯是“先看数据，再动参数”。当产线反馈“MERLIC 误判变多”，正确的第一步不是打开 .mvapp 调阈值，而是按时间点拉出三样东西：对应批次的 NG 图像、该时段的单次耗时分布、以及最近一次参数变更记录。如果 NG 图像本身亮度整体下降，问题在上游光源或曝光，改 MERLIC 阈值只会把问题掩盖成“参数越来越松”；如果耗时 P95 突然抬升而图像正常，问题可能在通信重试或磁盘写入，继续调算法参数同样无效。这个判断顺序，是运维职责边界在操作层面的体现。

生命周期中的“版本冻结”也值得单独强调。量产运维阶段应把 MERLIC 的 Recipe、相机参数、光源参数、通信映射表视为一个整体版本，任何一项变更都要走变更记录并保留回滚点。示例做法是：每次变更前导出当前 Recipe 与相机配置，记录变更原因、变更人、生效工位与时间；变更后至少观察一个班次的误检率、漏检率与 P95 耗时，确认无异常再关闭变更单。若一个班次内指标恶化，直接回滚到上一版本，而不是在产线上继续“微调”。