1. 并行与多工位测试系统架构

在单工位测试中，TestStand 的角色通常被简化为“按顺序调用测试代码并记录结果”。一旦进入并行与多工位场景，系统架构就变成决定吞吐量、稳定性和可维护性的第一要素。理解这一架构，需要同时看清五个对象：TestStand 引擎（Engine）、执行入口（Entry Point）、序列文件（Sequence File）、进程模型（Process Model）以及工位映射（Station Mapping）。它们不是并列的五个概念，而是一条从“谁发起测试”到“结果如何归属到具体工位”的完整链路。

一、引擎：并行能力的真正来源

TestStand 引擎是执行序列、管理变量、调度步骤和记录结果的运行时核心。它有两种典型使用方式：进程内引擎与独立引擎实例。在单工位、单线程场景中，操作界面（如 Sequence Editor 或自定义 Operator Interface）通常与引擎处于同一进程，调用简单、调试方便。但在多工位并行场景中，如果所有工位共用一个引擎实例，执行线程会相互阻塞，一个工位的等待（如等待仪器响应、等待操作员装夹）会拖慢其他工位，并行就退化为“轮流执行”。

因此，多工位架构的关键决策是：每个工位拥有独立的引擎实例。常见做法是每个工位对应一个独立进程，进程内启动自己的引擎；或者在同一进程内创建多个引擎实例，由不同线程分别驱动。前者隔离性更好，一个工位崩溃不会影响其他工位；后者资源占用更低，但需要更谨慎地处理线程安全和共享资源。选择依据通常是工位数量、单工位测试时长、仪器资源独占性以及故障隔离要求。

二、执行入口：谁在什么时刻启动测试

执行入口是外部系统触发 TestStand 执行的接口。它可以是操作界面上的“开始测试”按钮、PLC 发出的启动信号、MES 下发的工单，也可以是扫码枪读取产品序列号后自动触发。执行入口决定了测试的触发时机和上下文数据：例如工位号、产品序列号、测试程序版本、操作员 ID 等。这些数据必须在启动执行前写入引擎的输入参数或文件全局变量，否则后续序列无法正确区分不同工位和不同产品。

在多工位系统中，执行入口通常不是单一入口，而是“每工位一个入口”或“统一入口 + 工位路由”。前者实现简单，每个工位独立监听自己的触发源；后者适合集中调度，但需要额外的路由逻辑把任务分发到对应工位的引擎实例。无论哪种方式，入口层都必须保证：同一工位不会同时启动两个执行，否则会出现资源竞争和结果错乱。

三、序列文件：测试逻辑的载体与复用单元

序列文件（.seq）保存测试步骤、变量、类型定义和回调。在多工位系统中，序列文件的组织方式直接影响维护成本。常见有三种模式：

• 每工位独立序列文件：工位之间完全隔离，修改互不影响，但重复内容多，升级时需要逐个同步。
• 共享主序列 + 工位差异配置：测试逻辑写在共享序列文件中，工位差异通过参数或配置文件注入。复用性最好，但要求序列设计时把差异点抽象干净。
• 模板序列 + 工位覆盖：以模板为基础，工位通过覆盖特定步骤或变量实现差异化。适合工位间大部分相同、少量不同的场景。

选择哪种模式，取决于工位间测试内容的相似度和变更频率。若工位间差异超过 30%，强行共享反而会增加条件判断的复杂度，此时独立序列文件更清晰。

四、进程模型：隔离与资源的平衡

进程模型描述 TestStand 执行时与操作系统进程的关系。单进程多引擎适合工位数量少、仪器资源可共享的场景；多进程单引擎适合工位间需要强隔离、或每个工位绑定独立硬件资源的场景。多进程模式下，每个进程有独立的内存空间和异常边界，一个工位的未捕获异常不会导致其他工位停止，但进程间通信和结果汇总需要额外设计。实际工程中，“每工位一进程”是多工位测试最常见的起点，因为它把故障域限制在单个工位内，调试和部署也更容易理解。

五、工位映射：让结果找到自己的归属

工位映射解决的是“哪个执行属于哪个工位”的问题。它通常通过以下方式实现：在启动执行时把工位号写入引擎的 StationID 或自定义输入参数；在序列中使用该参数选择对应的仪器地址、测试阈值和报告路径；在结果记录时把工位号写入数据库或报表字段。没有明确的工位映射，多工位系统的结果就会混在一起，无法追溯，也无法做分工位的良率分析。

六、把五者串起来：一次并行执行的完整路径

假设一个三工位系统，工位 A、B、C 分别测试同一产品的不同功能模块。一次典型执行如下：

1. 工位 B 的扫码枪读取产品序列号 SN20240517-0042，触发执行入口。
2. 入口层把 StationID = "B"、SerialNumber = "SN20240517-0042" 写入 Engine #2 的输入参数。
3. Engine #2 加载共享主序列文件，根据 StationID 读取工位 B 的差异配置（如仪器地址 TCPIP::192.168.1.102::INSTR、测试阈值 Vmin=4.75V）。
4. 序列按步骤执行，调用工位 B 对应的测试代码模块，结果写入本地变量。
5. 执行结束后，结果记录回调把 StationID、SerialNumber、各步骤测量值和判定结果写入数据库。
6. 与此同时，Engine #1 和 Engine #3 各自独立执行工位 A 和工位 C 的测试，互不阻塞。

这条路径中，任何一个环节缺失都会导致问题：没有独立引擎，工位之间会互相等待；没有工位映射，结果无法区分来源；没有差异配置，所有工位会使用同一套仪器地址和阈值，测试要么失败，要么结果不可信。

七、常见误区与判断依据

第一个误区是“多工位就是多开几个 Sequence Editor 窗口”。Sequence Editor 是调试工具，不是运行时架构。真正的并行执行需要由 Operator Interface 或调度程序管理多个引擎实例，Sequence Editor 只用于开发和单工位验证。

第二个误区是“共享一个引擎实例也能并行”。TestStand 引擎的执行是线程化的，但共享引擎意味着共享变量空间和资源句柄。如果两个工位同时写入同一个文件全局变量，后写入的值会覆盖先写入的值，导致工位数据串扰。判断是否需要独立引擎的简单依据是：工位之间是否存在可写的共享状态。如果有，就应该隔离。

第三个误区是“工位映射只是加一个字段”。工位映射必须贯穿入口、执行和结果记录三个阶段。只在结果记录时加 StationID，而执行时没有用该标识选择配置，结果虽然能区分工位，但测试过程可能用错了仪器或阈值，数据仍然不可信。

理解这五个对象及其关系，是后续设计并行调度策略、优化测试节拍和排查工位间干扰的基础。架构清晰之后，并行才真正可控。