ALM重新验证半导体晶圆厂综合防灾STPA——半天内将损失场景从6个扩展到26个
VisualPro Tech Brief
完整性不应依赖记忆
重新验证半导体晶圆厂综合防灾STPA——半天内将损失场景从6个扩展到26个
半导体晶圆厂安全分析 | STPA与MCP实践 | 项目报告
STPAMCP集成可追溯性数据库Class覆盖率半导体晶圆厂
01概述（TL;DR）——半天内发生了什么变化
我们对某半导体晶圆厂消防、气体与设施综合防灾控制结构的现有STPA分析进行了重新验证。该结构从安全中心操作员（EHS/FMS Operator）出发，经由中央FMS/GMS综合监控服务器和现场安全联锁PLC，延伸至三类设备：洁净室空调与洗涤塔排气、OHT物料搬运，以及特种气体与化学品供应阀门——其控制行为与反馈均以图示方式定义。
关键在于工作方式。基于VisualPro STPA的MCP（Model Context Protocol）集成，AI智能体完成了所有查询、登记和修改，而人只负责语义判断。GUI操作次数为零。
| 累计指标 | 初始（原始版） | 最终（Rev 2.1） |
|---|---|---|
| 损失场景 | 6个（100%基于故障） | 26个（故障6个／非故障20个） |
| UCA | 8个 | 15个 |
| 危害／系统约束 | 5 / 5 | 6 / 6 |
| 追溯链断裂的危害 | 1个（H-5） | 0个 |
此次重新验证的核心发现并不是新增的场景，而是现有分析集中在哪里。原有6个场景全部基于故障，而涵盖设计判断与法规义务的Responsibility系列（Class 1，C1–C4）完全空白。随后的7项发现，全部是从这一空白反向推导出来的。
由工具告诉你还有哪些内容需要分析——因此，完整性不再取决于分析人员是否勤勉。
[图1] VisualPro Control Structure——晶圆厂综合防灾控制结构（红色为控制行为，蓝色为反馈）。图中的每一个箭头，都是15个UCA和26个损失场景所关联的位置。界面标签与项目数据一样为韩文。
02是什么让这一切成为可能——三个要素
1MCP集成——自然语言指令即STPA工作自动化
VisualPro内置MCP服务器，使AI智能体能够直接访问工具的数据模型。在本次工作中，人的输入只是“检查一致性”“登记这些场景”之类的自然语言，而实际的查询、登记和修改，均以API命令的形式在15种STPA实体类型（loss、hazard、uca、loss_scenario、5种关系类型等）上执行。
· 本次会话中智能体登记的数据：1个危害、1条系统约束、7个UCA、20个损失场景，以及约50条关系链接
· 每条命令都分两步——先describe（获取规格），再execute（执行）——智能体自行掌握数据模式，因此登记时不会出现格式错误：批量登记错误为零
· UCA ID（UCA-N-9、UCA-P-13）和场景编号按类型规则自动分配——完全无需手动编号
· 本次会话中智能体登记的数据：1个危害、1条系统约束、7个UCA、20个损失场景，以及约50条关系链接
· 每条命令都分两步——先describe（获取规格），再execute（执行）——智能体自行掌握数据模式，因此登记时不会出现格式错误：批量登记错误为零
· UCA ID（UCA-N-9、UCA-P-13）和场景编号按类型规则自动分配——完全无需手动编号
2可追溯性数据库——一致性审核变成“查询”可审核性
VisualPro将STPA数据以双向关系的形式存储：Loss → Hazard → UCA → Loss Scenario → Countermeasure。因此，“链条在哪里断开？”这一审核问题无需人工交叉核对，只需几次关系查询即可回答。借助同一机制，全部20条Loss↔Hazard双向链接得到了逐一验证——而基于文档的分析通常根本不会进行这项检查。
3Class原型覆盖率——空白变成数字完整性
由于每个场景都以数据形式带有Class标签，“66个原型案例中哪些是空白？”可以立即以矩阵形式得出。在基于电子表格的工作中，随着场景增多，编号、关联和分类会逐渐失控，覆盖率只能依赖分析人员的记忆。而在数据模型上，即使场景增至26个，追溯性、ID和关系依然保持完整，空白、断裂和偏向都能通过查询加以量化。
03仅凭查询发现的三项结构缺陷
这些缺陷是在工作开始时仅凭关系查询发现的。没有一项属于“分析错了”——三项都属于“分析是空的”。
| 发现的缺陷 | 发现方式 | 措施 |
|---|---|---|
| 危害H-5（应急电源丧失）的UCA和场景均为0个——追溯链完全断裂 | 每个危害执行一次关系查询 | 通过登记LS-11和LS-23恢复链条 |
| UCA-3和UCA-7没有损失场景 | UCA↔场景交叉核对 | 确定为后续场景的编写对象 |
| 控制行为“紧急手动切断”（操作员）没有UCA | 控制行为↔UCA映射 | 通过新增UCA-9和UCA-10解决 |
[图2] VisualPro Trace View——Loss → Hazard → UCA → Loss Scenario → Countermeasure链条。该链条中的LS-13是AI智能体在本次工作中登记的，登记后立即加入追溯链，并与任何既有记录一样可被查询和审核。界面标签与项目数据一样为韩文。
04空白揭示的七条事故路径
每一条路径即使所有部件均正常、所有测试均通过，也依然成立。每一项都表述为一个根据文档约一小时即可回答的审核问题，凡是答案为“否”的问题，就是一条现实存在的事故路径。
| # | 发现 | 为何被遗漏 | Class |
|---|---|---|---|
| 14 | 火灾模式 vs 气体模式——法规之间相互冲突 | 消防与气体安全的法规不同、设计承包商不同、图纸也不同，交叉评审从未进行 | 1-C4 |
| 15 | 未解除的Force标签——调试遗留的幽灵 | Force状态只显示在诊断画面深处，而逻辑评审只看源代码，不看输出强制覆盖 | 1-C23 |
| 16 | 把“无信号”解读为正常的默认设置 | 设计评审会考察“值错了怎么办”，却很少考察“收不到值时采取什么策略” | 1-C20 |
| 17 | 晶圆厂改造后的过时映射——MOC的盲区 | 值本身是正确的，因此任何自诊断都无法发现。出错的不是数据，而是坐标系 | 2-C7 |
| 18 | 复电陷阱——重新通电比停电更危险 | 停电演练和UPS测试针对的是断电的瞬间，设备恢复的顺序则未经测试 | 3-C7 |
| 19 | 作为共因的仪表空气 | 所有部件均正常，所有单机测试均合格。“所有区域同时动作”不在任何测试程序之中 | 3-C11 |
| 20 | 日程的背叛——日历不知道紧急情况 | 调度程序不被视为控制要素，因此从未出现在联锁矩阵中 | 4-C11 |
案例1——火灾模式 vs 气体模式（A-Ha #14）
火灾报警控制器发出的火灾信号，依据消防法规强制要求停止HVAC并关闭防火阀，以阻止烟气扩散。但在气体火灾中，停止排气就意味着气体积聚和二次爆炸风险。消防法规与气体安全要求同一个风阀执行相反的动作——这是法规层面的冲突。
1气体管道法兰处发生SiH4（硅烷）微量泄漏；由于硅烷接触空气即会自燃，局部火灾随之发生。
2火灾报警控制器探测到火灾，依据消防法规设置的联锁自动执行HVAC停止和防火阀关闭。
3与此同时，气体探测系统检测到泄漏——此时安全PLC本应发出将应急排气开到最大的指令。
4然而，排气路径上的防火阀早已被消防逻辑关闭。PLC的排气指令在物理上已经无效。
5未燃烧的气体在室内积聚、浓缩，二次爆炸风险（H-1）随之上升——这是两套安全逻辑各自“正确”动作的结果。
审核问题 当火灾信号和气体信号同时到达时，风阀与排气的优先级是否已写入设计文件？
案例2——作为共因的仪表空气（A-Ha #19）
紧急情况下，当所有区域的气动阀门和风阀同时动作时，仪表空气（IA）总管压力会下降，部分切断阀无法在规定时间内关闭。日常测试每次只动作一个阀门，因此这一问题永远不会被发现。
1日常的阀门功能测试每次只测一个阀门。IA需求始终有余量，测试每次都能通过。
2真正的紧急情况到来——大规模泄漏使所有区域的联锁同时触发。
3数十个气动阀门和风阀同时开始动作，IA总管压力急剧下降。
4部分阀门因供气不足、驱动扭矩不够，无法在规定时间内完全关闭（处于半开状态）。
5系统统计为“切断完成”，而气体仍通过半开的管线持续流出（H-1）。
审核问题 是否曾针对所有区域同时动作的场景计算IA需求量，或通过测试加以验证？
05三步工作流程与审核检查清单
这7项发现并非来自头脑风暴，而是来自在数据上执行的流程。工具在每一步承担了什么工作，决定了这种方法能够被复现。
| 步骤 | 专家的角色 | VisualPro的角色 |
|---|---|---|
| 1. 标签审核 | 从语义上对照案例原文与每个场景的因果结构 | 即时查询全部26个场景及其标签和链接；错误标签（LS-8）的修正只需一次保存即可生效 |
| 2. 覆盖率矩阵 | 从空白中筛选出在晶圆厂中确实可能发生的系列 | 根据Class标签数据自动计算66个案例 × 26个场景的映射 |
| 3. 反向推导与登记 | 将领域实体代入%slots%，设计审核问题 | 批量登记新的UCA、场景和关系；自动分配ID；即时建立追溯链接 |
要点 专家的时间全部用于语义判断。随着查询、交叉核对准备、登记和编号工作转交给工具，同样的半天时间里，分析从6个场景的体系推进到了26个场景的体系。
交付物即行动清单——设计审核检查清单
| # | 审核问题 | 需确认的文件 | 关联 |
|---|---|---|---|
| 1 | 火灾与气体信号同时出现时，风阀优先级是否已形成文件？ | 消防联锁设计文件、联锁矩阵 | LS-20 |
| 2 | 是否对PLC Force标签进行持续监控，并在交接班时进行检查？ | PLC操作规程、交接班日志 | LS-26 |
| 3 | 通信超时时，标签质量策略是否为“报警”？ | PLC逻辑标准、标签数据库 | LS-21 |
| 4 | 设备搬迁的MOC是否包括更新防灾映射？ | MOC程序文件、映射表历史记录 | LS-22 |
| 5 | 复电顺序是否已形成文件并经过测试？ | 复电程序文件、重启测试记录 | LS-23 |
| 6 | 所有区域同时动作时的IA需求量是否已计算并验证？ | 仪表空气容量计算书 | LS-24 |
| 7 | 定时动作是否设有紧急状态下的暂停条件？ | 自动测试日程设置、联锁清单 | LS-25 |
06功能与效果
本项目中观察到的各项效果，与产生这些效果的功能一一对应。所有数据均为本次会话的实测值。
| VisualPro功能 | 本次工作中的效果 |
|---|---|
| MCP服务器（AI智能体集成） | 以自然语言完成STPA查询、登记和修改。GUI操作为零，半天完成全部工作 |
| 从Loss到Countermeasure的追溯模型 | 仅凭查询发现三项结构缺陷——H-5追溯断裂、控制行为缺少UCA |
| 双向关系数据 | 对全部20条Loss↔Hazard关系进行穷尽式交叉验证——文档分析中通常会省略的检查 |
| UCA类型体系（N/P/T/S）与自动ID | UCA增至15个时，ID与类型仍保持一致；手动编号为零 |
| 支持不与UCA关联的场景 | 过程自主行为（Class 4）和传递失败（Class 3）系列也作为正式数据纳入 |
| describe/execute两步式API | 智能体在登记前确认数据模式——20次批量登记零错误 |
07常见问题（FAQ）
Q1什么是VisualPro的MCP集成？
VisualPro内置MCP（Model Context Protocol）服务器，使Claude等AI智能体能够直接访问STPA、FMEA、FTA、HARA和TARA数据模型。用户以自然语言下达指令，智能体通过工具的API命令执行查询、登记和修改。本次工作全程均以这种方式进行。
Q2AI登记的数据可信吗？
有两重机制。第一，每条命令都会在describe步骤返回必填字段和规则，因此智能体无法提交不符合数据模式的数据——本次会话中的批量登记错误为零。第二，登记后重新查询以验证结果是标准流程。语义层面的有效性仍由专家通过标签审核负责。
Q3与基于电子表格的STPA相比，决定性的区别是什么？
追溯性以数据形式存在。诸如“哪个危害没有场景？”“哪个控制行为尚未分析？”之类的完整性问题，都可以通过查询得到答案。本次工作中发现H-5追溯断裂和Responsibility系列的空白，就是明证。若基于文档，同样的问题需要人工逐项交叉核对。
Q4采用这一工作流程会带来哪些改进？
专家的时间将从查询、登记、编号、维护链接等机械性工作，转移到语义判断上——场景是否成立、设计是否站得住脚。在本案例中，将场景体系从6个扩展到26个并完成一致性审核，用时半天。
Q5同样的方法是否适用于STPA以外的分析？
是的。VisualPro MCP服务器除STPA外，还提供FMEA、FTA（含割集和PMHF计算）、HARA（含现代汽车标准）和TARA的命令，因此同样的自然语言、查询与登记、验证工作流程可以适用于整个安全分析领域。
08立即开始（Next Step）
STPA的难点不在于学习方法本身，而在于了解分析已推进到哪一步、还有哪些空白。用文档管理，这个问题的答案只存在于分析人员的记忆中；用数据管理，答案则以查询结果的形式返回。从已在半导体、汽车、国防、航空和机器人领域得到验证的VisualPro开始，让完整性成为结构本身的属性，而不是依赖任何人的勤勉。
让完整性成为结构的属性，而非依赖任何人的勤勉——VisualPro STPA。
本简报总结了VWAY解决方案事业部基于VisualPro STPA的MCP集成、与AI智能体协作完成的重新验证。累计数据集（6个危害、15个UCA、26个损失场景）及其追溯关系可在Semicon.vsa项目中查看。