4. 批量测量工程需求分析

批量测量工程与单次标定实验的最大区别，在于它把“测一次”变成“连续测很多次、很多台、很多工位”。需求分析的目标不是罗列功能，而是把场景、节拍、吞吐、精度和扩展性五条约束同时量化，形成可验证的设计输入。任何一条缺失，都会在后期以停机、丢数据或精度漂移的形式暴露出来。

一、批量测量场景：先分清“批”的边界

批量测量场景通常分为三类：同型号多台件（如一批 200 台传感器）、多型号混线（同一产线切换 3～5 种产品）、多工位并行（上下料、预热、测量、复检同时进行）。场景决定了系统是“单站串行”还是“多站并行”，也决定了数据模型是否需要按产品型号、批次号、工位号分层。

• 同型号多台件：重点是重复性与一致性，节拍稳定，数据可批量聚合。
• 多型号混线：重点是配方切换与防错，换型时间必须计入节拍。
• 多工位并行：重点是资源调度与数据归属，避免工位间串扰。

二、节拍要求：把时间拆到毫秒

节拍（Cycle Time, CT）是批量测量最硬的约束。需求分析时必须把总节拍拆解为：上料、定位、预热/稳定、采集、计算、判定、下料、通信开销。以 12 秒节拍为例，若采集与计算占 8 秒，则留给上下料和通信的余量只有 4 秒，任何一次重试都会直接拖垮产能。

节拍预算示例（单工位，目标 CT = 12 s）
上料/定位        : 2.0 s
预热/稳定        : 3.0 s
采集（N 次平均） : 3.5 s
计算与判定       : 1.5 s
下料/复位        : 1.5 s
通信与日志       : 0.5 s
合计             : 12.0 s  → 余量为 0，需预留 10% 缓冲

三、数据吞吐：从“点数”倒推带宽与存储

数据吞吐由三部分构成：采集吞吐（每秒采样点数）、传输吞吐（网络或总线带宽）、落盘吞吐（数据库/文件写入速率）。若每台件采集 8 通道、每通道 10 kHz、16 bit，则单台件原始数据率约为 8×10000×2 B = 160 kB/s；若节拍 12 s，单台件约 1.92 MB。按每天 2000 台件计算，日增原始数据约 3.8 GB，尚未计入日志、图像和中间结果。

四、精度指标：把“准”翻译成可测参数

精度指标不能只写“高精度”，必须落到重复性、再现性、线性度、迟滞、温度漂移等可测项。批量场景下，重复性（同一台件多次测量）和再现性（不同工位/不同时间测量）往往比绝对精度更关键，因为它们直接决定判定阈值是否可靠。

• 重复性：同一工位连续 10 次测量，标准差应 ≤ 满量程的 0.02%。
• 再现性：不同工位测量同一标准件，偏差应 ≤ 满量程的 0.05%。
• 线性度：在 20%、50%、80% 量程点，偏差应 ≤ 0.03% FS。
• 温度漂移：每 10 ℃ 变化，零点漂移应 ≤ 0.01% FS。

五、可扩展性设计：为“以后加一台”留接口

可扩展性体现在四个维度：工位扩展（从 1 站到 N 站）、通道扩展（从 8 通道到 64 通道）、产品扩展（新增型号不改代码）、数据扩展（新增指标不重建表）。设计上应做到配置驱动、接口标准化、数据模型分层。

可扩展配置示例（YAML）
station:
  id: ST-03
  channels: 16
  sample_rate: 10000
product:
  model: SENSOR-A
  points: [0.2, 0.5, 0.8]
  tolerance: 0.03
storage:
  raw: /data/raw/{date}/{batch}/
  result: /data/result/{model}/{station}/

六、综合案例与复盘

某压力传感器产线原设计节拍 15 s，实际运行 22 s，日产能不达标。复盘发现：预热时间被低估 3 s，采集重试平均 2 次，数据库逐条写入耗时 1.5 s。改进措施：预热与上料并行、采集失败仅重试 1 次、结果批量提交，最终节拍降至 13.5 s，日数据量 6.2 GB 稳定落盘。

综上，批量测量工程需求分析应围绕场景、节拍、吞吐、精度、扩展五个维度建立量化基线，并通过测试用例和监控项持续验证。只有把“需求”变成“可测参数”，批量测量系统才能在产能、质量和扩展之间取得稳定平衡。