2. MERLIC项目工程化起点

在MERLIC项目里，真正决定交付成败的往往不是“能不能识别”，而是“需求有没有被量化”。很多项目在演示阶段效果很好，一旦进入产线就出现漏检、节拍不达标、接口对不上、验收扯皮等问题，根源几乎都指向同一个环节：需求分析与可行性评估没有做扎实。本节的目标，是把一句模糊的“检测这个零件有没有缺陷”，拆解成可测量、可验证、可写入验收标准的工程参数。

一、需求分析要拆成六个量化维度

MERLIC项目工程化的起点，是把客户需求翻译成六个维度的量化描述：检测对象、节拍、精度、环境、接口、验收标准。这六项缺一不可，任何一项留白，都会在集成或验收阶段变成风险。

• 检测对象：材料、颜色、表面处理、尺寸范围、批次差异、来料姿态、是否反光/透明/柔性。
• 节拍：单件允许时间、是否多工位并行、触发方式、是否允许缓存。
• 精度：要区分的最小缺陷尺寸、允许的误检率与漏检率、重复性要求。
• 环境：光照稳定性、振动、粉尘、温度、相机安装空间与工作距离。
• 接口：PLC型号与协议、通信周期、IO点数、MES/数据库对接方式。
• 验收标准：用哪批样本、多少数量、判定阈值、谁签字、以什么数据为准。

以典型金属件表面缺陷检测为例，客户口头需求是“检出划痕和凹坑”。量化后应写成：检测对象为铝合金外壳，表面拉丝处理，尺寸约120mm×80mm；最小可接受缺陷为0.2mm宽、3mm长的划痕；节拍要求单件≤1.2s；误检率≤1%，漏检率≤0.5%；现场为24V PLC触发，需输出OK/NG及缺陷类型；验收以连续生产500件、人工复判一致率≥98%为准。这样的描述才能直接指导选型与开发。

二、可行性评估：先算清楚，再动手

可行性评估不是“感觉能做”，而是用参数反推硬件与算法是否成立。核心是三件事：光学分辨率是否够、节拍是否够、MERLIC工具链是否能覆盖。

光学分辨率用公式估算：视野宽度除以相机水平像素数，得到单像素对应的实际尺寸。若视野为150mm、相机为500万像素（约2448×2048），则单像素约0.061mm。要稳定检出0.2mm的划痕，缺陷至少占3~4个像素，即0.18~0.24mm，处于临界状态，建议提高分辨率或缩小视野。若改用1200万像素（约4024×3036），单像素约0.037mm，0.2mm缺陷约占5个像素，检测余量明显更充足。

节拍评估要区分“采集时间”和“处理时间”。假设曝光5ms、传输30ms、MERLIC处理400ms、PLC通信20ms，单件约455ms，满足1.2s要求。但如果加入多ROI、多个工具链或深度学习模块，处理时间可能上升到800ms以上，此时需要评估是否并行处理或降低分辨率。

MERLIC工具链可行性要逐项对照：定位用Locate或Align，测量用Measure，缺陷检测用Inspect或Check，分类可用Classify。若缺陷形态复杂、样本不足，则要评估是否引入外部模型或改用其他方案。

三、从需求到验收的量化拆解路径

把需求变成验收标准，需要一条清晰的拆解路径。下面这张图展示了从客户需求出发，经过六个维度的量化，最终落到硬件选型、MERLIC配置和验收判据的关系。

四、验收标准必须可执行

验收标准是需求分析的最终落点，也是最容易产生争议的地方。可执行的验收标准应包含四个要素：样本、数量、判据、责任人。

样本要覆盖正常件、边界件和缺陷件，且缺陷件应包含最小可接受缺陷。数量上，建议连续生产不少于500件，其中缺陷件不少于50件。判据要明确：漏检率≤0.5%、误检率≤1%、人工复判一致率≥98%。责任人要写清客户方与集成方各自的确认人。

在MERLIC中，验收数据可以通过Statistics工具或外部日志记录每次检测结果，导出CSV后统计。若发现漏检集中在某类缺陷，应回到可行性评估阶段重新检查光学方案或工具参数，而不是在验收现场临时调阈值。

五、一个可复用的需求量化检查表

下面这份检查表可直接用于项目启动会，逐项填写后作为可行性评估的输入。

完成这张表后，可行性评估就有了明确输入。接下来才是相机选型、镜头计算、光源设计和MERLIC工具链配置。需求分析做得越细，后续返工越少，验收越顺畅。