2. TestStand并行模型解析

在 TestStand 中，测试模型（Test Model）决定了序列文件如何被调用、测试流程如何流转、资源如何分配，以及结果如何汇总。很多工程师在优化节拍时，第一反应是“把并行打开”，但真正决定吞吐量的，是模型选择与工位资源是否匹配。Batch、Parallel、Serial 三种模型并不是简单的“快、中、慢”排序，它们对应不同的资源占用方式、同步机制和结果聚合逻辑。理解它们的差异，才能避免“并行后反而更慢”或“结果丢失”的典型问题。

三种模型的核心机制

Serial（串行模型）是最基础的执行方式：一个测试站按顺序执行一个 UUT（被测单元）的完整流程，完成后再取下一个。它的资源占用清晰，同一时刻只有一个测试线程在操作仪器，不存在资源竞争。缺点是仪器空闲时间长——当 UUT 在夹具中上下料、等待操作员或执行非仪器操作时，仪器处于闲置状态。串行模型适合单工位、低产量或调试阶段，也适合那些必须独占仪器资源的测试项。

Parallel（并行模型）允许同一测试站同时执行多个测试线程，每个线程对应一个 UUT。TestStand 通过并行执行（Parallel Execution）或并行测试模型，让多个 UUT 的测试序列同时运行。关键在于：并行的是“测试流程”，但仪器资源是否真正并行，取决于仪器是否支持多会话或是否被多个线程共享。如果两个线程同时访问同一台不支持并行的仪器，TestStand 会通过资源锁（Lock）让其中一个等待，此时并行退化为“交替执行”，节拍并不会按线程数线性缩短。

Batch（批处理模型）通常指将多个 UUT 作为一个批次统一处理：批次内的 UUT 可以并行测试，但批次之间按顺序执行，且批次结束时统一汇总结果。Batch 模型常用于需要“同批次一致性”的场景，例如同一批产品需要共用校准数据、同一温度条件或同一测试程序版本。它比纯 Parallel 多了一层批次边界，便于结果追溯和批次放行。

选择依据：从资源、节拍和结果三个维度判断

选择模型时，不要只看“能不能并行”，而要看三个约束：仪器是否支持并行访问、节拍瓶颈在仪器还是上下料、结果是否需要按批次聚合。

如果仪器是单会话资源（例如某些老式电源、串口仪器、GPIB 单地址设备），强行使用 Parallel 只会让多个线程排队等锁。此时更有效的做法是：把测试流程拆成“仪器段”和“非仪器段”，让非仪器段并行执行，仪器段串行化。TestStand 中可以通过 Lock 或资源管理器实现这种“部分并行”。

如果节拍瓶颈在上下料或操作员，而不是仪器测试时间，那么 Parallel 的收益会很明显：当 UUT1 在夹具中等待操作员时，UUT2 可以占用仪器继续测试。此时并行线程数不必等于工位数，通常 2～4 个线程就能覆盖上下料重叠，线程过多反而增加锁竞争和内存开销。

如果结果需要按批次放行，例如同一批产品必须使用同一校准系数、同一温度曲线，或者批次内任意一个失败就要整批隔离，那么 Batch 模型更合适。Batch 的代价是批次边界处的同步等待：上一批全部结束后，下一批才能开始。如果批次内 UUT 数量少、测试时间短，边界开销占比会升高。

一个可参考的配置示例

假设某测试站有 2 台可并行仪器（电源、数字万用表）和 1 台单会话仪器（程控电阻箱），单 UUT 测试时间约 45 s，其中电阻箱占用 12 s，上下料约 8 s。若采用 Serial，节拍约为 45 s + 8 s = 53 s。若采用 Parallel 双线程，电阻箱成为共享资源，两个线程在电阻箱段会互斥。按最坏情况估算，电阻箱段串行后，双线程节拍约为 (45 + 8) / 2 + 12 / 2 ≈ 32.5 s，提升约 39%。若把电阻箱测试项提前到上下料阶段并行执行，节拍可进一步压缩。

在 TestStand 中落地时，可以在 Station Globals 或序列文件中定义资源锁，例如为电阻箱创建名为 ResistorLock 的 Lock。在测试步骤前调用 Lock("ResistorLock")，测试完成后调用 Unlock("ResistorLock")。这样即使使用 Parallel 模型，也能保证单会话仪器不被并发访问。同时，在 Process Model 的回调中记录每个 UUT 的线程 ID 和开始/结束时间，便于后续分析锁等待时长。

常见误区与排障方向

第一个误区是“线程数越多越快”。实际上，当共享资源成为瓶颈后，增加线程只会增加上下文切换和锁竞争，总节拍可能不变甚至变长。第二个误区是“Parallel 模型下结果会自动按 UUT 分开”。如果多个线程写入同一个结果文件或同一个全局变量，结果会互相覆盖。正确做法是让每个线程使用独立的结果容器，或在写入时加锁。第三个误区是“Batch 就是慢”。Batch 的批次内仍然是并行的，它只是增加了批次边界；对于需要批次追溯的场景，Batch 反而能减少人工分组和结果整理时间。

排障时，可以按以下顺序检查：先确认仪器是否支持多会话；再确认测试序列中是否存在未加锁的共享资源；然后查看锁等待时间是否异常；最后检查结果文件是否按线程或 UUT 隔离。如果锁等待时间很短但节拍没有改善，瓶颈可能不在仪器，而在上下料、操作员或数据处理环节，此时应优先优化非仪器段，而不是继续增加并行线程。

总结来说，Serial 适合独占资源和调试，Parallel 适合多工位且仪器可并行或可拆分，Batch 适合需要批次一致性和追溯的场景。选择时先看资源约束，再看节拍瓶颈，最后看结果聚合需求。三者之间也可以组合使用：例如在 Batch 内部使用 Parallel 线程，对单会话仪器加锁，对可并行仪器放开并发。这种组合往往比单纯切换模型更贴近实际产线需求。