有一套测试软件，从第一版到现在跑了十几年。

这期间，扫描源换了两次，功率计换了一代，频谱仪从 PSA 换到了别的系列，计算机从工控机换成台式机又换成现在的小主机。操作系统的界面风格改了三回。

软件的主框架，一行没改。

不是没时间重构，是没必要——新仪器接进来，配一下驱动，加一个子 VI，跑通了。原来的扫描调度、数据融合、报表生成，原封不动。

这件事听起来像吹牛，但它成立的前提很具体：软件分层分对了。

三层，各管各的

任何一套要长期用的测试系统，结构上都得切成三层，切错了后面全是债。

第一层：会话层。
负责"怎么跟设备说话"。GPIB 也好，RS-232 也好，USB、网口也好，LabVIEW 里统一叫 VISA 会话。这一层的任务只有一个：把字节送出去，把字节收回来。不管底下是哪种总线，上层看到的都是同一个会话句柄、同一对读写函数。

这一层的价值，在系统二里体现得最清楚：一台 PC 上同时挂着 1 路 GPIB 和 5 路串口，六个设备并行跑。GPIB 上的 M419 收 $ 开头的字符串命令，串口上的温控器收 SCPI，另一台控制器收 Bisync 帧，还有一台计数器收纯 ASCII。

四种协议，语法完全不同。但因为都在 VISA 会话之上，代码里它们长得一样——创建会话、配置参数、写、读、关闭。业务层根本不需要知道对面是 GPIB 还是串口。

第二层：驱动层。
负责"这台设备具体怎么用"。波长怎么设、量程怎么选、触发模式怎么配、返回的字符串怎么解析成数值。

这一层是唯一跟型号绑定的一层。换仪器，改这里。

第三层：业务层。
负责"这次测试要干什么"。扫多少个点、每个点采哪几路、判据是什么、数据存哪、报表怎么出。

这一层是软件的资产。它包含了这些年积累下来的测量方法、判据经验、客户要求——这些东西跟仪器型号毫无关系，却最容易被写死在仪器操作里。

绝大多数"换台仪器就得重写"的软件，问题都出在第三层和第二层粘在一起了：扫描循环里直接拼 SCPI 字符串，判定逻辑里直接写死某个型号的量程上限。

同一个骨架，两套系统

回头看手边这两套系统，骨架居然是同一个：

系统一：激光扫波长（激励）→ 三台仪器采数（测量）→ 融合落库（存储）。5 台 GPIB 设备。

系统二：磁体扫场（激励）→ DVM 读离子流 + 计数器读计数（测量）→ 标定换算落库（存储）。1 路 GPIB + 5 路串口。

一个是光波长，一个是磁场；一个全是 GPIB，一个六路混搭；一个的时间尺度是毫秒，一个是秒。但抽象出来是同一件事：一个自变量扫一遍，若干因变量跟着采一遍，点对点绑定，成组落库。

所以调度逻辑可以复用：状态机管"设定—等待稳定—采样—存盘"这四步，队列管上下游衔接，断点续扫管异常恢复。这些跟具体是什么物理量无关。

真正要重写的，只有两件事：怎么设定自变量，怎么读因变量。

能碰多深，决定能做到什么程度

改造老系统的时候，还有一个比协议更根本的问题：你能控制到哪一层。

我习惯把它分四级：

A 级：协议公开，命令可读写。
手册里有完整命令集，能设能读，能改工作模式。系统一的那五台 Agilent、系统二的 5400 和 996，都在这一级。这一级能做到全自动。

B 级：有厂商 API 或驱动，但只开放部分功能。
能通过接口控制，但某些模式不给你切，某些参数不给你改。这一级能做自动化，但边界要提前摸清楚，别把方案建立在"应该能改"的假设上。

C 级：只能做文件级交互。
软件不能直接控制设备，但设备会把结果写成文件，或者能读入一个配置文件。这一级只能做"半自动"：人操作设备，软件读结果、做后处理、合并数据。

D 级：只读，联锁不能碰。
有些设备的安全联锁、硬件保护回路绝对不许软件介入。这一级要老实承认：软件只做监视和记录，控制权留给硬件。

分级的价值在于报价和承诺。 客户问"能不能全自动"，答案不该是"能"或"不能"，而应该是"你这台设备在哪一级"。A 级可以承诺全自动；C 级就得说清楚中间需要人操作一步；D 级谈自动化是给自己挖坑。

见过太多项目栽在这一步：方案阶段默认所有设备都是 A 级，实施时发现某台关键设备是 C 级，整个流程卡在那一环，工期和成本全崩。

反例：写死型号的代价

说个常见写法。

扫描循环里：
  发 "SOUR1:WAV 1550"     ← 直接把 SCPI 写死在业务代码里
  发 "SENS1:POW:RANG 0"   ← 量程也写死
  读 "READ1:POW?"
  判断 if 值 > 1.5 then 报警   ← 阈值写死在代码里

这个写法在原型阶段最快，一天能跑通。但它埋了四颗雷：

1. 换仪器，SCPI 语法变了 → 整个循环要重写
2. 换量程需求，得改代码重新编译
3. 阈值要调，得找写代码的人
4. 别人接手，看不懂 SENS1:POW:RANG 0 是什么意思

正确的写法是把这些抽出去：命令模板放在设备配置文件里，量程和阈值放在方法配置文件里。业务代码只面对"设定激励值"和"读取测量值"两个抽象。

判断一套代码写得好不好，有个很土的标准：把仪器型号从代码里全局搜索一遍。 如果型号出现在业务逻辑里，那这套代码换不了仪器。如果型号只出现在配置文件和驱动层，那换仪器就是换个配置。

框架能活多久，取决于你想了多远

一台质谱仪能用三十年，一套测试软件用十五年不算长。

在这十五年里，仪器会换、接口会换、操作系统会换、连做测试的人都可能换三茬。唯一不变的是"这个测试要测什么"——物理原理不会变。

所以架构设计的核心问题只有一个：哪些东西会变，哪些东西不会变，然后把它们隔开。

会变的：仪器型号、接口类型、通信协议、数据结构、界面风格。
不会变的：测量原理、扫描逻辑、判据依据、数据之间的关系。

把不会变的写进业务层，会变的推到配置和驱动层。这个道理不难，难的是在项目开始的第一周就想到——那时候所有人都在赶进度，都想"先跑通再说"。

先跑通没错，但要知道哪些地方是先跑通、后面必须还的债。

---

如果你手上有套跑了多年的测试软件，现在正卡在"换仪器就得重写"这一步，可以把仪器清单和现在的代码结构说一下。多数情况下不用推倒重来，把粘在一起的层剥开就行——工作量比想象的小，但顺序不能错。

#LabVIEW #软件架构 #仪器控制 #测试系统 #VISA