2. TestStand运行时架构
理解TestStand的运行时架构，是做好部署打包与产线发布的前提。很多工程师在开发机上把序列调通后，直接把整个开发环境拷到产线电脑，结果出现授权报错、界面弹不出、步骤找不到代码模块等问题。根源往往不是序列本身写错了，而是没有分清TestStand各组件在“开发态”和“运行态”中的角色差异。本节围绕引擎、序列编辑器、操作员界面、适配器四个核心对象，说明它们在部署时各自承担什么、哪些必须随包发布、哪些应当被剥离。
一、四个核心组件的职责边界
TestStand引擎（Engine）是真正执行序列的运行时内核。它负责加载序列文件、解析步骤、调度执行线程、管理变量作用域、处理回调与报告生成。引擎本身没有可视化界面，它以进程内组件或独立服务的形式存在。产线电脑上真正“跑测试”的是引擎，而不是序列编辑器。
序列编辑器（Sequence Editor）是开发与调试工具。它内嵌一个引擎实例，提供步骤编辑、断点、单步、变量监视、执行跟踪等能力。它面向的是开发者，不是操作员。部署到产线时，序列编辑器通常不应出现在操作员可接触的路径中，否则操作员误改序列会直接破坏产线一致性。
操作员界面（Operator Interface，OI）是面向产线人员的执行入口。NI提供多种现成OI（如Full-Featured、Simple、CVI、LabVIEW、.NET版本），也允许自定义。OI通过TestStand API连接引擎，启动指定序列文件、传入工位参数、显示测试进度与结果、控制“开始/停止/失败重测”等操作。OI是产线发布时必须随包交付的部分。
适配器（Adapter）决定步骤如何调用外部代码。常见适配器包括LabVIEW、C/C++ DLL、.NET、ActiveX/COM、Python、Sequence Adapter等。适配器在引擎执行到对应步骤时被激活，负责参数封送、类型转换、错误回传。部署时，序列中用到的适配器及其依赖的运行库必须一并安装，否则步骤会在运行时因“找不到适配器”而失败。
二、部署时“带什么、不带什么”
从上面的架构图可以看到，开发态与运行态共享引擎和适配器这两个执行要素，但入口和代码形态不同。部署打包的核心判断依据是：产线电脑上需要的是“能执行”的最小集合，而不是“能编辑”的完整环境。
必须随包发布的内容包括：
- TestStand运行时授权：产线电脑需要有效的TestStand Runtime License或部署授权，否则引擎无法启动。开发授权不能替代运行时授权。
- 引擎与运行时组件：通过TestStand Deployment Utility生成部署包时，引擎核心文件会自动包含。若手动拷贝，需确认
TestStand\Bin下的运行时DLL完整。 - 操作员界面：OI的可执行文件及其依赖的配置文件（如
.ini、.xml）、图标资源、语言包。 - 序列文件：
.seq文件及其引用的.ini配置、.csv数据文件、报告模板.xsl等。 - 适配器运行时：若序列使用LabVIEW步骤，需安装对应版本的LabVIEW Run-Time Engine；若使用.NET步骤，需确保目标框架版本匹配；若使用Python，需部署Python解释器及依赖包。
- 代码模块：LabVIEW的
.vi需已编译并随包发布，DLL需确认其依赖的VC++运行库已安装。
应当剥离或限制访问的内容包括：序列编辑器、开发用适配器配置、源码工程文件、调试断点配置、开发授权文件。产线电脑上保留序列编辑器会带来两个风险：一是操作员可能误改序列导致测试逻辑漂移；二是编辑器启动时会占用额外授权，可能与OI的引擎实例冲突。
三、适配器在部署中的关键检查点
适配器是部署中最容易出问题的环节。以下检查点建议在打包前逐项确认：
| 检查项 | 判断依据 | 常见故障现象 |
|---|---|---|
| 适配器类型与序列步骤匹配 | 序列中每个步骤的适配器类型在目标机已安装 | 步骤报“Adapter not found” |
| LabVIEW Run-Time版本 | 与开发时编译.vi的LabVIEW版本一致 | 步骤报“Version mismatch”或直接崩溃 |
| .NET框架版本 | 目标机已安装序列引用的.NET版本 | 步骤报“Could not load assembly” |
| DLL依赖项 | 用Dependency Walker确认无缺失DLL | 步骤报“找不到指定模块” |
| Python解释器路径 | 目标机Python路径与序列中配置一致 | 步骤报“Python not found” |
四、引擎实例的两种运行模式
TestStand引擎在运行时有两种典型模式，部署时需要明确选择：
进程内引擎（In-Process）：引擎作为OI进程的一部分加载。启动快、通信开销小，适合单工位、单序列的产线场景。此时OI崩溃会连带引擎一起退出，但产线通常可以接受重启。
独立服务引擎（Out-of-Process / Service）：引擎作为独立进程或Windows服务运行，OI通过远程接口连接。适合多工位共享引擎、需要长时间稳定运行、或OI需要频繁重启的场景。代价是配置更复杂，需要确认远程连接权限和端口。
五、部署包的最小验证流程
打包完成后，不要直接在产线电脑上“试跑”了事。建议在一台干净的、与产线同配置的电脑上执行以下验证：
- 安装部署包，确认安装过程无报错、无缺失依赖提示。
- 启动OI，确认界面正常加载，无授权弹窗或引擎连接失败提示。
- 加载目标
.seq文件，确认序列树完整、步骤无“红色感叹号”缺失标记。 - 执行一次完整测试流程，确认所有适配器步骤正常调用，报告正常生成。
- 检查报告文件中的步骤耗时、结果数据是否与开发态一致。
- 重启电脑，再次启动OI并执行，确认无“首次运行正常、重启后失败”的授权或路径问题。
这套验证流程的核心目的，是确认“引擎能启动、适配器能调用、代码模块能加载、报告能生成”这四个运行态基本条件同时成立。任何一项不成立，都说明部署包缺少对应组件或配置不正确。