2. 联动系统需求捕获

多仪器联动系统的集成失败，绝大多数不是出在通信协议或代码实现上，而是出在需求捕获阶段。当实验任务或产线任务被直接翻译成"把源表、示波器、电源连起来自动跑"时，真正决定系统能否验收的信息——触发时序、量程切换点、数据吞吐率、异常恢复策略——往往散落在操作人员的经验里，没有被写成可验证的条目。本节要解决的就是：如何从一段真实的实验或产线任务描述中，系统性地提取出仪器功能、性能指标、时序约束与验收标准四类需求，并让它们彼此可追溯。

一、需求捕获的四个维度

联动系统的需求可以按四个维度拆解，每个维度回答不同的问题，且相互约束：

• 功能需求：系统要完成哪些动作序列？例如"对DUT施加3.3V上电，延时10ms后采集1000个点的I-V曲线，再断电"。功能需求描述的是"做什么"，通常以任务步骤的形式出现。
• 性能指标：每个动作要满足什么量化要求？例如电压精度±1mV、采样率1MSa/s、单次测量周期不超过200ms。性能指标决定了仪器选型和量程配置。
• 时序约束：动作之间的时间关系是什么？例如"上电稳定后至少等待5ms才能触发采集"、"触发信号上升沿到首点采集的延迟不超过1μs"。时序约束是联动系统区别于单机操作的核心，也是最容易遗漏的部分。
• 验收标准：如何判定系统合格？例如"连续运行100次，I-V曲线重复性标准差小于0.5%"、"异常断电后系统能在3s内恢复到就绪状态"。

这四个维度不是并列的清单，而是存在推导关系：功能需求产生动作，性能指标约束每个动作的精度与速度，时序约束定义动作之间的衔接，验收标准则把前三者转化为可测量的判据。捕获需求时，应当沿着"任务描述→功能→性能→时序→验收"的路径逐层追问，而不是一次性罗列。

二、从任务描述到需求条目的追问方法

假设产线任务描述为："对每块电源模块进行上电老化测试，记录输出电压和纹波，剔除不合格品。"这句话包含的信息量远不足以驱动联动系统。需要按以下方式追问：

功能追问：上电电压是多少？老化时长多久？输出电压和纹波分别用什么仪器测？不合格品的判据是什么？剔除动作由谁执行——是联动系统发信号给分拣机构，还是仅记录标记？

性能追问：输出电压测量精度要求多少？纹波测量带宽需要覆盖到多少？每块模块的测试节拍是多少秒？这决定了电源、数字万用表、示波器的选型下限。

时序追问：上电后等待多久开始测量？输出电压和纹波是同时测还是分时测？如果分时测，切换过程中是否需要保持供电？测试完成后多久断电？

验收追问：连续测试多少块算通过？测量数据的重复性要求？系统故障时如何标记当前模块？

经过追问，一段模糊的任务描述可以转化为一组可执行的需求条目。例如：

这张表本身就是需求捕获的交付物。它的价值在于：每一条需求都有编号、有类型、有可验证的方式，后续的系统设计、仪器选型、软件开发和验收测试都以此为依据。

三、时序约束的捕获要点

时序约束是联动系统需求中最容易遗漏、也最容易导致集成失败的部分。捕获时序约束时，需要明确三个要素：触发源、响应对象和时间容差。

以"上电后等待200ms再启动测量"为例，触发源是电源输出达到设定值的事件，响应对象是测量仪器开始采集，时间容差是±20ms。如果只写"上电后测量"，实现者可能理解为电源指令发出后立即测量，而实际电源输出建立需要时间，导致测量到错误的电压值。

更复杂的时序约束涉及多台仪器的协同。例如源表扫描电压的同时，示波器需要同步采集瞬态响应。此时需要明确：源表扫描启动信号是内部触发还是外部触发？示波器是等待外部触发还是自由运行？两者的时间基准是否一致？这些问题的答案直接决定了是否需要额外的触发同步模块。

四、验收标准的可测量化

验收标准必须是可测量的，否则无法判定系统是否合格。"系统运行稳定"不是验收标准，"连续运行8小时无通信超时"才是。将模糊要求转化为可测量标准，通常需要明确四个要素：测量对象、测量条件、测量方法和合格判据。

以"测量重复性"为例：测量对象是同一标准件连续测量10次的输出电压值；测量条件是环境温度25±2℃、电源预热30分钟；测量方法是计算10次读数的标准差；合格判据是标准差小于0.5%读数。这四个要素缺一不可，否则验收时会产生争议。

对于产线任务，验收标准还需要考虑节拍和异常处理。例如"单块测试周期不超过45秒"是节拍要求；"通信中断后自动重连，重连时间不超过2秒，重连失败则标记当前模块并继续下一块"是异常处理要求。这些标准应当在需求阶段就写入，而不是等到调试阶段再补。

五、需求捕获的常见陷阱

在实际工程中，需求捕获阶段有几个反复出现的陷阱，值得特别警惕。

陷阱一：把仪器能力当作系统需求。例如"使用34461A数字万用表"是选型决策，不是需求。需求应该写"电压测量精度±0.05%读数+3mV"，至于用哪台仪器实现，是设计阶段的事。把仪器型号写进需求，会限制后续的选型灵活性，也容易掩盖真正的指标要求。

陷阱二：遗漏异常路径。需求捕获时容易只关注正常流程，忽略通信超时、仪器报错、DUT短路等异常情况。这些异常路径的处理方式——是重试、跳过还是终止——直接影响系统的可靠性和验收结果。建议在捕获正常流程后，专门追问"如果这一步失败，系统应该怎么做"。

陷阱三：时序约束只写顺序不写时间。"先上电再测量"只描述了顺序，没有描述时间间隔。在实际系统中，上电后立即测量和上电后等待200ms测量，得到的结果可能完全不同。凡是涉及物理量建立、仪器量程切换、滤波器稳定的环节，都必须给出明确的时间约束。

陷阱四：验收标准与需求条目脱节。验收标准应当逐条对应需求条目，而不是另起一套。如果某条需求没有对应的验收方法，说明它要么不可验证，要么在验收时会被忽略。建议在需求表中直接增加"验证方式"一列，确保每条需求都有明确的判定手段。

六、需求捕获的交付物

需求捕获阶段的最终交付物是一份结构化的需求规格说明，至少包含以下内容：需求条目表（编号、类型、描述、验证方式）、时序约束清单（触发源、响应对象、时间容差）、验收测试大纲（测试项、测试条件、合格判据）。这份文档是后续系统设计、仪器选型、软件开发和验收测试的共同依据，也是多仪器联动系统集成工程中最重要的基线文档之一。

从实验或产线任务出发捕获需求，本质上是一个"翻译"过程：把操作人员头脑中的经验、任务书上的模糊描述、工艺文件中的指标，翻译成工程师可以设计、可以验证的条目。翻译的质量，直接决定了联动系统最终能否通过验收。