📚 课程目录第2章半导体设备软件需求分析与可验证性设计

2. 半导体设备软件需求分析与可验证性设计

半导体设备软件的需求分析，难点不在“写出功能”，而在于把设备规格中的物理指标，翻译成软件能够承担、能够验证、能够追溯的条目。UPH（单位小时产能）、MTBF（平均无故障时间）、颗粒度（污染控制水平）、温控精度这些指标，往往由机械、电气、工艺、软件共同决定。软件需求分析的核心任务，是明确软件在这些指标中“负责哪一段”，并把这段责任写成可测试的条目。

一、从设备规格到软件需求：先划边界，再定条目

设备规格是整机指标，不能直接当作软件需求。以某刻蚀设备为例，整机规格可能写着：UPH ≥ 60 片/小时、MTBF ≥ 200 小时、颗粒度 ≤ 0.05 个/片（≥0.09μm）、温控精度 ±0.5℃。软件需求分析的第一步，是判断每个指标中软件可影响的部分。

UPH 由传输时间、工艺时间、换片时间共同决定。软件能控制的是传输路径调度、并行动作编排、配方切换时间。因此软件需求应写成“在标准配方下，软件调度使单片传输时间不超过 X 秒”，而不是“UPH ≥ 60”。MTBF 中软件可影响的是异常恢复、看门狗、通信重连、日志完整性。颗粒度中软件可影响的是阀门动作顺序、抽气/充气时序、机械手运动轨迹与速度曲线。温控精度中软件可影响的是采样周期、控制算法、前馈补偿、加热器功率输出分辨率。

规格到需求的翻译原则：整机指标 → 软件可影响因子 → 软件行为约束 → 可测量条目。每一步都要保留来源，否则追溯矩阵会断链。

二、需求条目化：每条需求必须可测、可追溯、可判定

需求条目化的标准格式建议包含：需求编号、需求描述、来源规格、验证方法、通过判据、优先级。以刻蚀设备温控为例：

REQ-TEMP-001
描述：软件应以 100ms 周期采集腔体温度，并在温度偏差超过 ±0.3℃ 时启动前馈补偿。
来源：整机温控精度 ±0.5℃
验证方法：注入阶跃扰动，记录温度响应曲线
通过判据：稳态偏差 ≤ ±0.5℃，超调 ≤ 1.0℃，恢复时间 ≤ 8s
优先级：高

这条需求把“温控精度”拆成了采样周期、触发条件、补偿动作、可测判据。验证时不需要等整机跑完，只需在仿真环境注入扰动即可。类似地，颗粒度需求可写成“在抽气阶段，软件应保证阀门 V1 先开、V2 后开，间隔 200±20ms”，验证方法是记录阀门时序日志。

三、需求追溯矩阵：让每条需求都有来源和归宿

追溯矩阵不是形式主义，它解决三个问题：规格是否被覆盖、需求是否被测试、变更是否影响下游。矩阵的行是需求条目，列是来源规格、设计模块、测试用例、验证状态。刻蚀设备软件的一个简化追溯矩阵如下：

需求编号	来源规格	设计模块	测试用例	状态
REQ-TEMP-001	温控精度 ±0.5℃	温控服务	TC-TEMP-STEP	已覆盖
REQ-PART-002	颗粒度 ≤ 0.05 个/片	阀门时序控制	TC-VALVE-SEQ	已覆盖
REQ-UPH-003	UPH ≥ 60 片/小时	传输调度	TC-TRANS-PAR	待验证
REQ-MTBF-004	MTBF ≥ 200 小时	异常恢复/看门狗	TC-RECOVERY	已覆盖

矩阵中“待验证”不是失败，而是提醒当前测试尚未闭环。每次需求变更，必须检查矩阵中对应行是否更新，否则会出现“规格改了、软件没改、测试没测”的典型漏洞。

四、可测试性需求编写：把“能测”写进需求本身

可测试性不是测试阶段才考虑的事，而是需求阶段就要写进去的约束。可测试性需求通常包括：可观测性、可注入性、可隔离性、可重复性。以刻蚀设备为例：

可观测性：软件应提供温度、压力、阀门状态、机械手位置的实时日志，采样周期 ≤ 100ms，时间戳精度 ≤ 1ms。
可注入性：软件应支持在仿真模式下注入温度阶跃、通信延迟、传感器漂移等故障，注入接口不影响正常控制路径。
可隔离性：温控服务、传输调度、配方管理应能独立启动和测试，不依赖真实硬件。
可重复性：同一测试用例在相同初始条件下，连续运行 10 次，结果偏差应 ≤ 5%。

这些条目本身就是需求，必须进入追溯矩阵。没有可测试性需求，后续自动测试只能靠人工临时搭环境，效率低且不可复现。

五、刻蚀设备需求分解实战：从一条规格到一组条目

假设整机规格要求“颗粒度 ≤ 0.05 个/片（≥0.09μm）”。软件需求分解过程如下：

识别软件相关环节：颗粒主要产生于抽气/充气瞬间的湍流、阀门切换顺序、机械手运动扬尘。软件负责阀门时序和机械手速度曲线。
定义行为约束：抽气阶段 V1 先开、V2 后开，间隔 200±20ms；充气阶段 V3 先开、V4 后开，间隔 150±15ms；机械手在腔体上方速度 ≤ 200mm/s。
写成需求条目：REQ-PART-002、REQ-PART-003、REQ-PART-004，每条都带来源规格、验证方法、通过判据。
设计测试用例：TC-VALVE-SEQ 记录阀门时序日志，TC-ROBOT-SPEED 记录速度曲线，TC-PARTICLE-SIM 在仿真环境统计颗粒模拟值。
回填追溯矩阵：确认每条需求都有来源、有测试、有状态。

同样的方法可用于 UPH。整机 UPH ≥ 60 片/小时，意味着单片节拍 ≤ 60 秒。软件分解为：传输调度并行化、配方切换时间 ≤ 5s、机械手取放片时间 ≤ 12s、腔体抽气/充气时间 ≤ 18s。每条都写成可测条目，并在仿真环境中用虚拟时钟加速验证。

常见误区：把整机规格直接抄成软件需求，导致需求不可测、不可追溯。例如“软件应保证 UPH ≥ 60”无法直接测试，因为 UPH 还取决于机械、工艺、来料。正确做法是拆到软件可控的节拍、时序、调度参数上。

六、可测试性设计的落地检查

需求写完后，用以下问题自查：每条需求是否有唯一编号？是否有来源规格？是否有验证方法？是否有量化判据？是否能在仿真环境独立执行？变更时是否能通过追溯矩阵找到受影响的设计和测试？如果这些问题都能回答，需求分析才算闭环。

刻蚀设备软件的需求分解实战表明：设备规格是起点，软件可影响因子是桥梁，需求条目是终点，追溯矩阵是保障，可测试性需求是让验证自动化的前提。五者缺一不可。