2. 在线检测需求分析与指标定义

在线检测系统的架构不是先画出来的，而是被一组可量化的需求指标“逼”出来的。节拍决定相机数量与处理链路，精度决定光学分辨率与算法路径，误检率和漏检率决定判定阈值与复核机制，稳定性决定冗余与温控策略，可追溯性决定数据存储与索引结构。本节的核心任务，是把客户口中的“要快、要准、要稳”，翻译成架构上可执行、可验证的约束条件。

一、从需求语言到指标语言

需求分析的第一步是消除模糊表述。例如“检测要快”必须落到“单件检测周期 ≤ 800 ms”；“不能漏检”必须落到“漏检率 ≤ 0.1%”；“误报太多”必须落到“误检率 ≤ 2%”。这些指标之间并非独立，而是相互制约：提高精度往往增加处理时间，降低漏检率通常抬高误检率。架构设计的本质，是在这些矛盾中寻找可实现的平衡点。

一个可操作的转化方法是“指标—约束映射表”。以某金属件表面缺陷检测为例，假设需求为：节拍 60 件/分钟、最小缺陷 0.1 mm、漏检率 ≤ 0.2%、误检率 ≤ 3%、连续运行 24 h、每件可追溯。下面逐项展开其架构含义。

二、节拍如何转化为架构约束

节拍 60 件/分钟即单件周期 1000 ms。若采用单相机单工位方案，则从触发、曝光、传输、处理到判定必须在 1000 ms 内完成。假设曝光 5 ms、传输 20 ms、算法处理 300 ms、通信与执行 50 ms，总耗时约 375 ms，看似充裕。但实际产线存在抖动，且需预留 30% 余量，因此单工位可行。

若节拍提升到 120 件/分钟，单件周期降至 500 ms，处理链路必须压缩到 350 ms 以内。此时架构上通常有三种选择：一是提高相机帧率并缩短曝光，二是将算法拆分为粗定位与精检测两级流水，三是增加工位并行处理。并行工位虽然提高吞吐，但会引入工位间一致性校准问题，需要在架构中增加标定与同步机制。

三、精度如何转化为光学与算法约束

最小缺陷 0.1 mm 是精度指标的核心。根据采样定理，缺陷在图像中至少应占 3～5 个像素才能稳定识别。取 4 像素，则像素当量需 ≤ 0.025 mm/pixel。若视野为 100 mm × 80 mm，则相机分辨率至少为 4000 × 3200 像素，即约 1200 万像素。这就是精度对相机选型的直接约束。

像素当量确定后，还需考虑镜头畸变、景深和光照均匀性。若景深不足，工件高度波动会导致边缘模糊，等效降低精度。因此架构中必须包含机械定位或自动对焦模块。算法侧则需明确：是否使用亚像素边缘提取、是否需要多帧平均降噪。这些选择会反向影响处理时间，进而影响节拍预算。

四、误检率与漏检率的架构含义

误检率（过杀）和漏检率（漏杀）是一对矛盾指标。漏检率 ≤ 0.2% 意味着在 1000 件中最多允许 2 件漏判；误检率 ≤ 3% 意味着最多允许 30 件误判。若算法判定阈值设置过严，漏检率下降但误检率上升；阈值放宽则相反。

架构上通常采用“两级判定”来同时满足两者：第一级用高召回率算法快速筛出疑似缺陷，第二级用高精度分类器或人工复核确认。第一级允许较高误检率，第二级负责压低最终误检率。这种结构要求系统具备缓存、队列和复核接口，属于典型的架构约束。

五、稳定性与可追溯性的架构落地

连续 24 h 运行意味着系统不能因单点故障停机。架构上需考虑：相机与光源是否独立供电、算法进程是否具备看门狗、图像存储是否采用环形缓冲避免磁盘写满。稳定性指标通常转化为 MTBF（平均无故障时间）和 MTTR（平均修复时间）约束，例如要求 MTBF ≥ 2000 h、MTTR ≤ 15 min。

可追溯性要求每件产品的检测图像、判定结果、时间戳和工件 ID 可关联查询。这直接约束了数据存储架构：若每天 10 万件、每件图像 2 MB，则日增数据约 200 GB。若要求保存 30 天，则需约 6 TB 存储，并建立按时间与工件 ID 的索引。若采用本地磁盘，需考虑 RAID 与清理策略；若上传 MES，则需定义接口协议与断网缓存机制。

六、指标冲突时的优先级决策

实际项目中，指标往往无法同时最优。此时需要与客户明确优先级。例如，安全件检测中漏检率优先级最高，允许误检率适当放宽；而大批量低价值零件检测中，误检率过高会导致复核人力成本上升，此时需平衡两者。架构上可通过“可配置阈值 + 统计看板”实现动态调整，而不是在代码中写死。

综上，需求指标分析不是罗列数字，而是建立“指标—约束—验证”的闭环。节拍约束处理链路，精度约束光学与算法，误检漏检约束判定结构，稳定性约束冗余设计，可追溯性约束数据架构。只有把这些约束显式写入架构设计，在线检测系统才能在真实产线中稳定达标。