工业 HMI 设计规范

面向设计师与工程师：当界面背后是一套正在运行的生产装置，让受训的操作员在连续值班中读得出过程状态、察觉得到异常、分得清屏幕上的数字还算不算数，并且在必要的时候安全地把手放上去。

工业 HMI 是操作员在控制室或现场监视与操作生产过程的界面——SCADA 上位画面、DCS 操作站、PLC 就地面板、以及带在身上的移动巡检终端。它与消费级产品的根本差异有四条：用户是受过训练的专业人员，但培训不能替代清楚的状态、对象和后果表达；值班是连续的，一个人要在一段班次里持续面对同一套画面；后果落在设备与人身上，一次误操作的代价不由撤销按钮承担；以及大量时间处于"没事发生"的监视状态，界面在绝大多数时刻的任务不是被使用，而是让人相信现在确实没事——并在有事的那一刻让人立刻知道。

这个领域最常见的设计错误，是把它写成一套工业风视觉规范：深色背景、拟物仪表、三维立体管道、扫光动效、一屏塞满的仪表盘。这些决定关于外观，而这个领域出事的地方几乎都不在外观上——是二十条报警在三十秒里一起涌出来而没有一条能被处理，是画面上的数字已经十分钟没有更新而看起来和正常刷新时一模一样，是操作员以为回路在自动而它两小时前就掉回了手动，是一个被强制成"正常"的点位在检修后没人记得取消。外观正确、上述任何一条不成立，都是不合格的 HMI。因此本规范以行为要求为主，并给出画面、状态与验证的落地方法；具体视觉参数按使用环境校准。

本规范由六条原则和 36 条规则组成：原则说明设计方向，规则规定适用情境、行为要求与验证方式。每条规则归属且仅归属一条原则，规则编号即原则编号（IH3-2 就是第三条原则下的第二条规则）。六条原则按规范对象切分：过程状态在界面上的呈现、报警这一类信号本身、显示值与其数据来源之间的关系、设备当前所处的控制模式、操作员发出的控制动作、以及跨时间跨人跨工位的值班过程。

范围声明本规范约束工业 HMI 在监视与操作上对操作员作出的体验承诺及其兑现机制的性质，不预设唯一的技术架构，不指定组态软件、通信协议或画面工具。本规范不替代任何强制性安全标准；当本规范的条款与适用的强制性标准、行业规范或场所的运行规程冲突时，以适用的强制标准与规程为准，本规范让位。采用本规范不能替代下列专项评估与合规判定：功能安全等级的判定与认证（安全完整性等级的定级、验证与独立评估属于功能安全标准体系，本规范只把"界面不得替代安全功能"写成设计要求，不作任何定级）、工艺设计与控制算法（回路整定、先进控制、优化策略与工艺参数不在本规范范围内）、工业网络安全（分区、认证、远程访问与工控网络防护须按适用的网络安全标准另行评估）、硬件与环境防护（防护等级、本安、防爆、抗振与温度范围由设备规格决定），以及控制室的建筑与工效学布置、人员资质与培训认定、事故调查与责任判定。上述任一项与本规范条款冲突时，以适用的法规、标准与规程为准。

阅读顺序：第 1—3 章定义原则与 36 条规则，第 4 章统一术语，第 5 章规定交付与验收方法；附录 A 提供故障注入场景，附录 B 说明证据边界。配置决定记录在《工业 HMI Design Token》，外部依据见 reference.md。

---

1. 六条原则¶

六条原则按规范对象切分设计责任：每条原则管辖一类对象上的义务，每条规则按其义务的直接规范对象归属唯一原则。对象不同，原则就不会互相替代——这是切分的依据，也是检验切分的方式。

同一个场景可以触及多条原则——夜班两点，一台泵的出口压力变送器通信中断：产品同时面对该数值还该不该被当成实时值呈现（IH3-1）、由此产生的报警是否可操作以及会不会连带引发一串下游报警（IH2-1、IH2-5）、依赖该测点的自动回路是否已经掉回手动而操作员是否知道（IH4-2）、以及这件事在四点交班时要不要作为一项交接对象（IH6-3）。这不是分类错误：四条规则约束的是四个不同规范对象上的义务，一个是数据可信度的呈现，一个是报警信号本身，一个是控制模式，一个是值班过程的连续性。互斥与穷尽是这套切分接受检验的主张，不是宣布即成立的事实：规则增删或归属存疑时，按附录 A 的分类检验验证。检验不过，修改的是原则的切分。

本切分中最需要持续检验的两处边界，在此明示：IH1 与 IH3——IH1 管"这个值怎么呈现才能被读懂、这个偏离怎么呈现才能被察觉"，IH3 管"这个值到底还代不代表现实"。同一个压力数字，问题若是它没有单位、没有量程、看不出正在上升，归 IH1；问题若是它是五分钟前的最后一次成功读数却和实时值长得一样，归 IH3。IH4 与 IH5——IH4 管控制模式这一状态：它是什么、怎么被知道、什么条件下会变；IH5 管控制动作：谁有权发出、怎么核对、留下什么痕迹。切换模式这件事两边都沾，归属依据是义务的直接规范对象："当前模式必须一直看得见""自动退出的条件与后果必须可查"的对象是模式状态，归 IH4；"发起一次模式切换需要什么权限、要不要二次核对、记录里留下什么"的对象是这次动作，归 IH5。这两处若在实践中反复出现归属争议，应当调整原则而不是增设中间层。

原则用于理解规则与裁决归属，本身不作为单独的判定条目。当原则与具体条款的解读出现冲突时，以适用条款为准，并记录需要澄清的歧义。

规则归属唯一，不等于机制不能复用。一套"数据质量状态"既决定数值怎么呈现（IH3-2）、也决定基于该测点的报警要不要被抑制（IH2-4）、还决定依赖它的自动回路要不要退出（IH4-6）；一份"当前被强制与被旁路的点位清单"既是可信度的一部分（IH3-4）、是操作留痕的对象（IH5-5），也是交接班必须移交的内容（IH6-3）。同一机制一物多用是常态，写在哪条取决于义务的直接规范对象。

2. 规则的读法¶

2.1 每条规则的结构¶

一句话概括各部分的效力：规则正文规定要求；适用与边界条件共同限定要求的适用范围；设计应用、验证示例、反例与依据参考不另行增加义务。

规则写行为性质、不写实现方式：通信中断之后画面必须能被看出不再刷新，这是产品行为；用心跳、用时间戳比对、还是用质量码驱动一层遮罩，是工程方案——两者必须对得上，但不是同一份交付物。

2.2 约束词¶

规则正文使用三级约束词：

• 必须：不满足即不符合本规范。缺了它，某条对操作员的承诺会在可预见的情境下失效——这是标「必须」的唯一依据。
• 禁止：与「必须」同等强度的反向表述，指明不得出现的行为；正文中的「不得」与「禁止」等价。
• 应当：默认遵循；确有理由偏离时，记录理由与替代做法，并接受同样的验证。偏离不需要审批，但需要留痕。「不应当」是「应当」的反向表述。

合规判定以正文中的独立义务子句为单位：无约束词的陈述句承接所在规则标题的强度；显式标注约束词的子句按其自身强度判定——【应当】规则内的「禁止／不得」子句仍是硬约束（IH1-4、IH2-6、IH3-5、IH3-6、IH4-6、IH6-2、IH6-4、IH6-5 含此类子句），规则标题与速查表的强度标注不替代子句约束力。正文中的「不能」仅用于能力或事实陈述，不表达义务。

强度表示约束力，不表示重要性。本规范中任何一条的强度标注都不改变适用的强制性安全标准的效力：强制标准要求更严时以强制标准为准，本规范不构成放宽的依据。

2.3 反例的两侧¶

反例分两侧："做不到"是漏掉这条要求，"做过头"是为了满足它而把界面堆成另一种失效。工业 HMI 被做坏的方式在两端都很密集：一端是把所有异常都配成报警、把所有数字都涂成红色、把每次点动都加一层确认；另一端是为了"高性能画面"而把整个界面做成一片灰、正常时几乎没有可读信息，操作员只好另开一个自己攒的 Excel 看数——把人赶去用影子工具，同样是没做对。克制不等于把信息藏起来，谨慎不等于让每次操作都变慢。

2.4 规则速查：36 条¶

下表是全部规则的一句话记忆版，点击规则名可跳到第 3 章的完整正文。速查不替代各条的适用条件与完整要求；个别【应当】规则内含禁止级子句（IH1-4、IH2-6、IH3-5、IH3-6、IH4-6、IH6-2、IH6-4、IH6-5），判定以正文为准（见 2.2）。

IH1 正常安静、异常显著

IH2 报警是被管理的资源

IH3 显示不比数据更确定

IH4 控制模式始终在场

IH5 操作有授权、有核对、有痕迹

IH6 值班是连续的

3. 规则详解¶

本章按六条原则展开全部 36 条规则。每条的结构与各部分的约束力见 2.1；其中的设计应用、验证示例与反例只是帮助落地的说明，不指定唯一组件，也不要求新增独立交付文档。

3.1 IH1 正常安静、异常显著¶

这条原则管的是过程状态在界面上的呈现。工业 HMI 的注意力预算是稀缺的：操作员一个班次里绝大多数时间面对的是没有异常的画面，界面每多占一份注意力，异常出现时可动用的就少一份。因此本原则的核心不是"把重要的东西做醒目"，而是把视觉强度按偏离程度分配出去——正常态让位，异常态取用。同时，被读到的信息必须能被解释：一个数字只有带上量纲、量程与它此刻相对于正常范围的位置，才构成过程信息。

IH1-1视觉强度按偏离分配必须¶

一句话：一切正常的时候，界面应该是安静的。

适用持续显示过程状态的监视画面。

规则画面上的对比、饱和度、闪烁、动效与声音等注意力资源必须按"偏离正常运行的程度"分配；处于正常范围内的量值与状态禁止使用为异常状态保留的呈现方式。产品必须显式定义哪几档呈现分别对应正常、需要关注与需要动作，并保证同一档在全部画面上含义一致。任何一档呈现方式被用于非状态用途（品牌色、分区底色、装饰）时，必须与状态档位在视觉上可区分。

边界条件本条不要求界面是灰的，也不禁止使用颜色——它要求的是强度的分配关系，不是绝对的色板。深色背景与浅色背景都可以满足本条；把界面整体降到读不出数值的程度不满足本条（见 IH1-3）。本条也不管报警本身该不该产生，那是 IH2-1。

设计应用先给"正常"定一档低强度呈现，再把剩下的强度留给偏离；给每一档写出判据（在正常范围内／超出运行范围但未达报警／已达报警），并让判据由数据驱动，而不是由画面制作者逐个手工上色。

验证示例

• 用户侧：在装置全部正常运行的状态下截屏，核对画面上没有使用为异常状态保留的呈现方式，且关键数值可读；随后在同一画面注入一处偏离，检查它在产品所定义的察觉条件下能否被发现。（全部正常时不存在过程偏离，强度最高的元素可以是导航、主数值或选中反馈，据此判定不成立。）
• 实现侧：核对状态档位的定义是否集中管理并被全部画面引用，是否存在画面局部自定义的告警色。

反例做不到——正常运行时管道、设备与背景大面积使用高饱和色，异常出现时它没有更高一档可用；做过头——把全部元素压到极低对比，操作员为了看清一个数字要凑近屏幕，或转而依赖自己维护的表格。

IH1-2颜色不是唯一编码必须¶

一句话：换成灰度打印也要读得出来它是什么状态。

适用以颜色表示设备状态、数据质量、报警等级或模式的界面。

规则用颜色表示状态时，颜色禁止是唯一的编码方式；每一类由颜色承载的状态区分，必须同时由形状、图案、位置、文字标签或数值中的至少一种独立表达，且该非颜色编码在不放大、不悬停、不点击的条件下可得。颜色与非颜色编码必须来自同一状态定义，禁止出现两者不一致的呈现。本条同样适用于大屏、打印件与移动终端；单色或低色域显示设备上，状态区分必须仍然成立。

现场可辨认性必须有声明的使用条件：按终端记录观看距离、角度、照度、反光、显示缩放及所用字号与对比度；不能只检查桌面截图。关键状态与操作反馈必须有文字或符号等可感知路径；支持键盘或辅助技术的终端，焦点、控件名称与状态通知必须可用，常规刷新不得夺走输入焦点。声音提示不得作为关键异常的唯一线索；其可闻性应当在现场噪声与实际防护装备下验证。

边界条件本条不禁止用颜色，也不要求每个状态都配一段文字；一个形状差异或一个位置差异就足以满足"独立表达"。本条不规定具体色值与对比度数值，那由产品按适用的可辨别要求与现场照度确定并记录依据。

设计应用把"状态"做成一个带图形与文本两种表现的对象，两者由同一个字段驱动；在设计评审阶段用灰度渲染整套画面走一遍关键判断。

验证示例

• 用户侧：以灰度呈现关键画面，请操作员判断各设备处于运行、停止、故障还是不可用；判断不成立即为不合格。
• 实现侧：检查是否存在只改颜色不改其他属性的状态渲染分支。

反例做不到——泵的运行与停止只靠绿与灰区分，色觉差异或屏幕老化后无法分辨；做过头——每个图元都挂一段状态文字，画面被文字填满，反而看不出布局关系。

依据与参考R09 说明颜色须被区分性地使用（同一颜色不得既表示危急报警又表示设备停止），R10 的厂商风格指南明确状态呈现不能只依赖颜色、须另用填充、形状或简短文字。两者均为公开可取的设计资料，不是标准要求；具体色值与对比度不在本规范范围内（见 reference.md R09、R10）。

IH1-3数值带量纲、量程与限值必须¶

一句话：一个没有单位和范围的数字不构成过程信息。

适用显示过程变量数值的界面。

规则显示过程变量时，必须同时可得工程单位、量程或正常运行范围，以及该值相对于已配置限值的位置；禁止只呈现裸数值。单位与量程可以就近显示，也可以由稳定的画面约定承载，但不得要求操作员依赖记忆或翻阅文档才能解释。数值的有效位数必须与测量能力相称，禁止以超出测量分辨能力的位数暗示精度。同一变量在不同画面上的单位与量程必须一致，换算须显式说明。接受数值输入时（设定值、限值、参数），输入控件必须同时可得该值的工程单位与允许范围，并在提交后如实呈现系统实际接受的值——因取整、量化、限幅或速率限制使接受值不同于输入值时，该差异必须被明示，禁止以输入值回显冒充已生效值。

边界条件本条不要求每个数字旁都画一根量程条；"相对于限值的位置"可以由数值本身的状态呈现（IH1-1 的档位）承担。本条不规定小数位数的具体取值，由产品按测量链的实际能力确定并记录依据。

设计应用把单位、量程、限值作为测点定义的一部分随值一起提供，而不是画面上的静态文字；限值变更时数值呈现随之改变，不需要重新制图。

验证示例

• 用户侧：请操作员在不查资料的前提下说出某个数值的单位、正常范围以及它离报警还有多远。
• 实现侧：抽查画面，统计有多少数值缺少单位或量程来源；核对限值来自配置而非画面硬编码。

反例做不到——画面上一排数字"382 / 1.7 / 96"，只有资深操作员知道分别是什么；做过头——每个数值都配一条量程刻度、一段说明和一个迷你趋势，单屏信息密度高到无法快速扫视。

IH1-4变化趋势可得应当¶

一句话：一个点看不出过程在往哪走。

适用显示随时间连续变化的过程变量的界面。

规则对用于判断过程走向的关键变量，产品应当提供变化趋势的取得方式——趋势线、变化方向指示、变化率或与前一时段的对比皆可；趋势的时间跨度应当可调，并显式标出跨度与采样方式。趋势图上禁止把缺失、坏值或通信中断期间的数据以插值方式连成正常曲线（见 IH3-2）。哪些变量属于"关键"由产品按工艺与操作任务确定并记录依据，不由画面篇幅决定。

显示趋势曲线时，必须标出变量、单位、时间窗口、实时跟随或历史查看状态，并使采样或聚合方式可查。自动缩放、双纵轴、平滑或降采样不得掩盖越限、峰值与变化方向；坐标变化必须可见，必要时保留极值。回看历史不得把历史值放入实时控制面板；退出回看后按当前数据重新核对操作条件。

边界条件本条不要求每个测点都常驻趋势曲线；按需调出、悬停展开或专门的趋势画面都可满足。本条不规定趋势的默认时间跨度。

设计应用把"当前值 + 走向"作为一个整体的呈现对象；对判断加减速有意义的变量，给出变化率而不只是方向箭头。

验证示例

• 用户侧：给定一个稳定值与一个正在缓慢上升但尚未越限的值，请操作员区分两者。
• 实现侧：在数据源中制造一段空洞，检查趋势曲线是否显示为断开或标注缺失，而不是直连。

反例做不到——只有报警才能让人发现某个温度已经连续爬升四小时；做过头——每个画面都铺满曲线，关键变量与无关变量在视觉上无差别。

IH1-5画面层级与监视任务对应必须¶

一句话：第一眼要能回答"现在整体是否正常"。

适用由多幅画面组成的监视系统。

规则画面组织必须与监视任务的粒度对应：必须存在能够回答"当前整体是否正常、异常在哪个区域"的概览层，并能从该层到达对应的区域与设备细节；禁止要求操作员靠逐幅翻阅画面来确认全局是否正常。每一层画面必须声明它负责回答什么问题，同一问题不得散落在互不引用的多幅画面上。层级的深度与划分依据由产品确定并记录理由，不由组态工具的默认结构决定。

边界条件本条不规定层级的具体层数与命名，也不要求概览必须是一幅单独的画面——常驻的区域状态条同样可以承担概览职责。跨画面的导航与返回要求见 IH6-1，共享大屏与个人工位的分工见 IH6-2。

设计应用先写出每一层要回答的问题，再决定画什么；概览层放"是否偏离"与"偏离在哪里"，把具体数值留到下一层。

验证示例

• 用户侧：在概览层注入一处区域异常，记录操作员定位到具体设备所需的步骤数与是否需要翻页搜索。
• 实现侧：核对每幅画面是否有声明的职责，是否存在职责重复且内容不一致的画面。

反例做不到——只有一套按管道走向绘制的工艺流程图，判断全局是否正常必须把十几幅图挨个点开；做过头——为了"层级完整"做出五层画面，操作员在紧急处置时要点四次才能到达执行按钮。

依据与参考R14 认定关联的进出流量分置于不同显示页面妨碍了操作员判断，并把该情况与另一起事故中“只分段显示装置局部而无完整总览”的控制系统对照；R15 记载关键储罐的显示窗口被压在其他窗口之后，须有意识地调到前面才能看见。两者是事故调查结论，不是显示设计规则（见 reference.md R14、R15）。

IH1-6装饰不承载语义也不争夺注意力必须¶

一句话：立体管道和拟物仪表不是读数的路径。

适用使用三维立体、拟物控件、渐变、阴影、贴图或背景图像的界面。

规则装饰性表现禁止成为读取过程信息的唯一路径，也禁止使用与状态档位（IH1-1）相同或更强的视觉强度。拟物化的仪表、立体管道、光泽与阴影在本规范中不作为过程信息的载体：它们可以存在，但去掉之后画面必须仍能完成全部监视与操作任务。动画与动效仅在表示实际发生的过程变化或系统状态时使用，禁止用持续动效表示"正在正常运行"这一无偏离状态。

边界条件本条不禁止工艺流程示意图，也不要求界面必须是二维平面；示意图承担的是空间关系与连接关系，这属于信息而不是装饰。本条不针对配色风格作出规定。

设计应用做一次"去装饰测试"——把阴影、渐变、贴图与三维效果全部关掉，检查是否还能读出全部状态；不能读出的，说明信息本来就挂在装饰上。

验证示例

• 用户侧：以关闭装饰后的画面让操作员完成一组典型监视任务，比较错误与耗时。
• 实现侧：检查是否有状态仅由光泽、阴影或立体角度表达。

反例做不到——阀门的开关状态只由三维模型的角度表现，远看分不清；做过头——为了"高性能"把工艺连接关系也一并去掉，画面变成一张数字表格，操作员失去了对物料走向的判断依据。

3.2 IH2 报警是被管理的资源¶

这条原则管的是报警这一类信号本身。报警的作用是把操作员的注意力从别处调过来，因此它的总量必须被当成一份预算来管理——报警数量是设计指标，不是运行结果。这条原则约束的是报警的产生条件、分级依据、抑制与消解方式，以及泛滥期的呈现。本原则与 IH1 的分界是：IH1 管界面怎么呈现偏离，IH2 管什么偏离配得上一条报警。

IH2-1每条报警都要有人能做的事必须¶

一句话：没有操作员响应动作的信号，不配置为报警。

适用产生报警的系统。

规则每一条被配置为报警的信号，必须存在操作员在当班条件下可执行的响应动作，并且该动作在报警发生的时间窗内仍然有效；不存在任何仍有用、具体可执行的评估、控制、减缓或升级响应时，禁止把该信号配置为报警——它可以是事件、是日志、是状态显示，但不占用报警通道。某一后果已经发生、或某一项响应的窗口已过，不自动取消其他仍然有效的响应所支撑的报警资格：泄漏已开始而隔离仍然有效、超温已造成损失而撤离仍然必要，都属于本条允许的报警。报警的资格记录必须逐条写明响应动作、该动作意图达成的效果、其仍然有用的最晚时刻或条件、以及承担该动作的角色，禁止以一个笼统的"后果已发生"布尔值判定资格；记录须在配置时形成并在报警回顾时可查。仅需记录的事件不因配置了醒目样式或高等级颜色而取得报警资格。报警的新增、抑制与修改须经合理化与变更过程管理；抑制期间保留现存保护，抑制状态可查询。

边界条件本条不要求响应动作一定由操作员本人完成——"通知谁、上报到哪里"也是响应动作，但必须具体到可执行。本条不禁止记录无需响应的事件，只禁止把它们放进报警通道。本条也不要求为已完成、已结束的事件补配响应动作以保留其报警属性："只值得记录的完成事件"与"初始后果已发生但仍需立即减缓"是两类，前者不得为凑数量硬编响应，后者不得仅因已发生而自动降为日志。

设计应用给每条报警的配置项加一栏"操作员要做什么"，写不出来的取消其报警属性；定期回顾那些从未被响应的报警，它们通常是本条的违例。

验证示例

• 用户侧：从一段时间的报警记录中随机抽取若干条，请当班操作员说出各自的响应动作；说不出的属于本条违例。
• 实现侧：统计配置中没有记录响应动作的报警条目数量。

反例做不到——设备通电、阀门到位、批次开始都被配成报警，一个班次几百条无人处理；做过头——为了压缩数量把真正需要响应的低等级报警一并降级为事件，操作员失去了早期干预的机会。

依据与参考R04 引述的报警定义以“需要响应”为要件，R05 显示 EEMUA 191把 alert／event／prompt 与“非报警”作为与报警并列的单独主题处理，R13 说明过程状态指示不应被指定为报警。R04 为厂商对标准的解读，R05 仅取得公开目录（见 reference.md R04、R05、R13）。

IH2-2报警负荷是设计指标必须¶

一句话：报警数量在设计时就定下来，不是运行出来的结果。

适用产生报警的系统。

规则产品必须在设计阶段显式定义报警负荷的目标——包括稳态下的报警速率、可接受的峰值以及"泛滥"的判定条件——并使其可测量、可持续观察；实际负荷超出目标时必须触发处置流程（复核配置、消除根因、调整限值），禁止把观测到的实际速率直接当作可接受值。目标值、其依据与观测结果必须可查。同一操作岗位上叠加多个来源的报警时，负荷按岗位合计计算，不按子系统分别计算。

目标合理性必须以操作任务验证：在正常、开停车、工况切换和典型异常中，分别测量发现、理解、决定、操作及效果等待的耗时与漏处置情况；可用响应窗口来自工艺后果分析，不能用当前报警平均速率反推。持续观察高频重复报警、长期活动报警、抑制数量与超窗未响应项，避免只靠总量达标。采用死区、触发延时或恢复延时治理抖动时，必须定义其单位、作用对象与对报警延迟的影响，并验证真实快速异常仍有足够响应时间；禁止仅在显示层隐藏重复事件来伪造负荷下降。

边界条件本规范不给出具体的报警速率数值——公开文献中的基准值有其调查范围与装置类型前提，直接移植到不同工艺与不同岗位并不自动成立。本条要求的是目标被显式定义、有依据、被测量并被用于决策，数值由产品按适用的行业实践与自身测定确定并记录来源。

设计应用把报警速率与泛滥次数纳入常规运行报表，与工艺指标一起复核；把"最常发生的十条报警"作为固定的改进入口。

验证示例

• 用户侧：调阅最近一段时期的报警负荷统计，检查是否存在超出目标后的处置记录。
• 实现侧：核对系统是否具备按岗位统计报警速率与泛滥事件的能力，统计口径是否被记录。

反例做不到——从不统计报警速率，操作员默认一半报警可以不看；做过头——为了让统计数字达标而批量关闭报警，不改根因也不留记录（此举同时违反 IH2-4）。

依据与参考R13 记载某起事故爆炸前 11 分钟内两名操作员需处置的报警条数，R11 载有一张标称转述自标准的报警性能指标表。本规范不采用其中任何数值：R11 的表出自厂商白皮书对标准转述，R13 的数值自标为引自指南的转引，本次均未取得标准正文（见 reference.md R03、R11、R13 与附录 B.2 第 1 条）。

IH2-3分级依据后果与剩余响应时间必须¶

一句话：优先级不由设备贵重程度或提出方决定。

适用对报警划分优先级或等级的系统。

规则报警优先级必须由后果的严重程度与留给操作员的响应时间共同决定，并使用统一的判定依据；禁止以设备价格、所属专业、提出部门或供应商默认值决定优先级。各优先级的呈现方式与响应期望必须有明确差异，且高优先级的数量必须受控——当高优先级报警占比使其失去"优先"含义时，视为分级未落实。优先级的判定依据与每条报警的定级理由必须可查，并在工艺或设备条件变更时复核。

边界条件本条不规定优先级的档数，也不规定各档的占比数值；占比由产品按自身工艺确定并记录依据。本条不处理报警之外的一般提醒分级。

设计应用把定级做成一张两维判据表（后果 × 可用响应时间），让所有专业按同一张表定级；对定级为最高档的报警设置单独的评审。

验证示例

• 用户侧：抽取若干条不同优先级的报警，请两名未参与配置的人按判据表独立定级，比较一致性。
• 实现侧：统计各优先级的报警条目数与实际发生数的分布。

反例做不到——所有报警都是"高"，或每个专业按自己的习惯定级；做过头——把判据表拆到十几档，定级过程复杂到无人愿意复核，实际仍按经验随手选。

IH2-4报警状态分明，抑制可见且可恢复必须¶

一句话：暂不呈现的报警可清点，并按各自条件恢复。

适用产生或显示报警的系统；确认、消音、锁存、抑制与停用要求按实际支持能力生效。

规则报警暂不呈现的原因必须可区分为操作员搁置、按已定义工况的自动抑制、检修停用，以及其他已说明机制，禁止以一个统称掩盖它们的不同恢复语义。每一项必须可清点，并含原因、责任主体、开始时刻、恢复条件、复核要求，在一份可随时调阅的清单上可见。三类机制的恢复分别成立：操作员搁置应当有上限与到期处理，到期自动回归并被告知；按工况抑制随其已验证的工况解除条件自动恢复；检修停用按规定的恢复投用核验解除，复核期限到期不得自动等同于已具备投用条件。禁止提供无记录、无责任主体、无恢复路径的永久隐匿入口。长期抑制项必须进入复核，但持续时长本身不证明配置错误——停机工况持续很久不使按工况抑制成为违例。

报警的激活状态、操作员确认状态、声音状态与锁存状态必须分别表达：确认不证明异常已消失，消音不证明已确认或已处理，锁存复位不等于设备重新启动。确认请求必须绑定到正确的报警及其事件状态；新发生的需确认状态禁止被旧的确认静默覆盖。系统重启后上述状态须被重建或明示为未知，不得默认为已确认。确认可按系统约定同时消音，但必须记录两项实际结果；消音不能反向推定已确认。批量确认必须绑定操作时已明确的事件集合，不能把执行期间新到达的报警一并确认。无锁存能力时标为不适用，不能伪造“已复位”。

边界条件本条不禁止抑制——抑制是控制报警负荷的正当手段；它要求的是抑制的可见性与可回归性。永久取消一条报警属于配置变更，走变更流程而不是抑制机制。本条不要求任一类停用都必须由人工恢复，也不要求任一类都必须自动恢复——要求的是每类机制各自声明其恢复方式。本条不规定采用何种协议模型表达这些状态。

设计应用把"当前被抑制的报警"做成常驻可达的一处清单，并在概览层给出计数；到期回归时以明确的方式告知当班人员，而不是悄悄恢复。

验证示例

• 用户侧：搁置一条报警后交接班，检查接班人员能否发现它、能否知道它何时回来；另请操作员就任一异常回答"它是否仍在、谁已确认、何时由谁恢复"三问。
• 实现侧：检查是否存在绕过清单的屏蔽路径（工程师站直接改配置、局部画面自定义过滤）；分别构造"活动未确认→确认但仍活动→恢复正常但仍未确认→消音后又来新报警→确认请求指向已结束的旧事件→检修未完成但复核期已到→自动抑制条件解除→重启后状态重建"八种情形，核对各状态未被合并为一个"已处理"。

反例做不到——夜班把吵人的报警"点掉"，此后再没人知道它被关过；做过头——每次抑制都要求填写长表单并等待审批，操作员在泛滥期无法及时使用抑制手段，转而拔掉音响。

依据与参考R04 说明搁置、按设计抑制与停用三种状态各有不同的管理含义，R12 要求按装置模式决定某值是否报警。R04 为二手核验，R12 为核能监管审查导则，其适用对象与流程工业不同（见 reference.md R04、R12；状态联动与事件绑定另有 R27、R28 的公开原文支持）。

IH2-5泛滥期有专门的呈现与首出判别必须¶

一句话：洪水来的时候，一条滚动列表帮不上忙。

适用可能出现报警泛滥的系统。

规则系统必须为报警泛滥提供区别于常态的呈现方式，至少支持：按关联关系分组或折叠，使操作员看到的是若干组而不是逐条刷屏；首出判别或明确的不可判定结果：来源具备分辨能力时指出最先发生的那一条或那一类，证据不足时标为“顺序不可判定”；以及保留事件时序证据及其限制（见 IH3-5），支持事后分析。泛滥期间禁止以丢弃、静默截断或只保留最新若干条的方式减少显示，除非被丢弃的部分仍完整保留并可调阅且这一事实被明示。滚动列表在泛滥期不作为唯一呈现方式。

列表交互必须保留操作对象：刷新与重排不得让按下时的报警变成释放时的另一条；筛选、折叠与暂停滚动必须显示其范围、隐藏项或新增项计数，并保留恢复全局视野的入口。局部筛选不能消除岗位级关键报警提示。界面没有显示条目，必须能区分“当前无报警”“被筛选隐藏”“尚在同步”和“数据失效”。

边界条件本条不要求系统自动给出根因结论——分组与首出是帮助人判断的信息，不是诊断结果；系统给出的关联性推断必须与实际发生的事实分别标识。本条不规定"泛滥"的判定阈值，那由 IH2-2 定义。

设计应用把关联关系（设备从属、工艺上下游、共因）作为报警配置的一部分预先定义，而不是等泛滥时靠时间戳猜；给操作员一个"只看每组第一条"的视图。

验证示例

• 用户侧：注入一次典型的连锁跳车，记录操作员识别出最先发生事件所需的时间与是否需要事后翻查历史。
• 实现侧：检查泛滥期间是否有报警被静默丢弃，被丢弃的是否可完整调阅。

反例做不到——跳车瞬间两百条报警按时间倒序刷过，最先发生的那条被顶到列表之外；做过头——分组算法把不相关的报警合并成一条，掩盖了一个独立的新问题。

依据与参考R12 §4.1.2-6 说明首出处理识别一组相关参数中最先越限者，并指出在响应特性时变的场合其有用性受限；§4.6-3 要求首出显示在主工作站与装置总览上可得。R05 显示首发报警是 EEMUA 191单独命名的主题（仅目录可见）（见 reference.md R12、R05）。

IH2-6报警可取得响应指引但不替代规程应当¶

一句话：报警告诉你出事了，不告诉你全部该怎么做。

适用提供报警响应指引、处置提示或推荐动作的系统。

规则每条报警应当能够就近取得其响应指引——可能原因、需要确认的信息、可执行的动作与升级路径；指引应当与现行运行规程保持一致并注明来源、适用工况与维护责任。指引禁止被表述为对规程的替代或对规程的解释权来源；当指引与适用规程冲突时，以规程为准，且冲突本身应当被记录并触发复核。由系统自动生成或按经验统计得出的建议动作，必须与来自规程的内容分别标识（见 IH3-6）。

边界条件本条不要求把整份规程搬进界面；指引可以是一段摘要加一个指向规程的入口。本条不要求为每一条低等级报警都编写指引。

设计应用把指引与报警配置绑定并关联同一份权威规程来源，规程更新时指引一并失效待更新，而不是各自维护两份文本。

验证示例

• 用户侧：随机抽取报警，检查其指引是否可在处置时间内取得、内容是否与现行规程一致。
• 实现侧：检查指引内容与所关联规程的对应关系，是否存在长期未更新的指引。

反例做不到——报警只有一行代码化的文本，新员工需要打电话问班长；做过头——每条报警弹出一整页处置流程强制阅读，操作员在紧急时被文本挡住操作入口。

3.3 IH3 显示不比数据更确定¶

这条原则管的是屏幕上的每个值与它背后的数据来源之间的关系。工业 HMI 的画面是一层转述：数值经过传感器、变送器、控制器、通信链路与画面刷新才到达眼睛，这条链路上任何一环出问题，画面都可能继续显示一个看起来完全正常的数字。本原则的要求只有一句：界面呈现的确定程度不得高于它实际掌握的程度。它不要求系统更准确，只要求系统对自己不准确的部分保持诚实——不确定的要看得出不确定，过期的要看得出过期，被人改过的要看得出被人改过。本原则与 IH1 的分界见第 1 章：IH1 管这个值怎么呈现才读得懂，IH3 管这个值还代不代表现实。

IH3-1实时值与最后已知值可分辨必须¶

一句话：这是现在的数，还是最后一次读到的数。

适用显示来自远端数据源的过程值的界面。

规则正在更新的实时值与"最后一次成功读取到的值"必须在界面上可分辨，且该区分在不悬停、不点开、不查日志的条件下可得。呈现最后已知值时，必须同时可得该值的取得时刻或已过时长；产品必须定义各类值判定为"不再实时"的条件，并使该条件与数据源的实际更新特性相称。禁止在数据源已停止更新后继续以实时值的呈现方式显示该值。周期本就很长的量值（如人工录入的化验数据、按班统计量）不因此被判为过期，但其更新周期必须可得。

数值不变不等于采集停止。变化上报、死区上报与周期采样必须分别声明活性证据；来源时间、接收时间、最近成功核验时间不可混用，刷新浏览器时间不得使缓存变成新值。仅有通信心跳可证明链路活性，不能单独证明传感器正在正常测量；若无法区分，必须标明证据限制。

边界条件本条不要求所有值都常驻显示时间戳；一处状态标识加一个可取得的时刻即可满足。本条不规定判定过期的时长数值——该时长由产品按每类数据源的实际更新周期确定并记录依据。整幅画面级别的停止刷新另见 IH3-3，数值本身的质量另见 IH3-2。

设计应用把"值 + 取得时刻 + 是否实时"作为一个整体的数据对象向画面提供，而不是让画面各自决定要不要显示时间；对更新周期差异很大的量值，按数据源分类设定过期判据，而不是全系统一个阈值。

验证示例

• 用户侧：切断一路数据源后请操作员在画面上指出哪些值已经不再是实时值，并说出各自是什么时候的数。
• 实现侧：核对过期判据是否按数据源分类配置，是否存在画面直接缓存上一帧数值并照常渲染的路径。

反例做不到——通信中断后压力值停在 1.8 MPa，与正常刷新时的呈现完全一致，操作员据此判断装置平稳；做过头——给每个数值都加一行秒级刷新的时间戳，画面上一半的字符在不停跳动，真正的过期标识淹没其中。

IH3-2数据质量显式表达必须¶

一句话：坏值不得渲染成零，也不得渲染成上一个好值。

适用数据源能够给出质量、状态或有效性信息的系统，以及可能出现坏值、超量程、断线与未初始化值的界面。

规则数据的质量状态必须在呈现上被表达，至少区分可用、存疑与不可用三类；禁止把不可用的值渲染成一个看起来正常的数——包括渲染为零、渲染为量程下限、渲染为上一个有效值，或以默认值填充。质量状态必须随值一起流转到该值实际存在的每一个消费方：画面、趋势、报表与报警判断使用同一份质量信息，不得出现画面显示坏值而报警仍按该值计算的情况；产品不得以不登记某个消费方的方式规避本条。存疑一档的具体含义、产生条件，以及它在各消费用途下是否可继续参与计算，必须被分别定义并可查——存疑不自动等于"按最保守处理"，报表、趋势与报警判断可以对同一份存疑值作出不同的、已定义的处置，但不得由各自的默认行为决定。

质量、质量证据是否已知、人为覆盖、取得时刻、最后一次有效核验时刻与保护旁路状态，必须分别保留，不得合并为一个判断。没有质量证据时呈现为未验证，禁止以"刷新正常"证明值可用；保护旁路的标识绑定受影响的保护功能与对象，不以测量来源是否改变为前提——被旁路的联锁下，传感器读数可能仍然为真，失效的是保护关系。

边界条件本条不要求界面把底层协议的质量码原样显示给操作员；要求的是这些质量差异不被抹平。本条不规定质量分类的档数下限之外的细分方式，也不要求所有数据源都能提供质量信息——不能提供时，产品必须按 IH3-1 以时效性作为可得的替代判据并标注为未验证，时效正常不构成质量可用的证明，该限制须被记录。本条不要求所有消费方一律丢弃存疑值；要求的是每个用途的处置已被定义。

设计应用把质量作为数值对象的固有属性而不是附加装饰；在趋势、统计与报警三处分别确认坏值的处理方式已被显式定义（跳过、断开、标注），而不是由各自的默认行为决定。

验证示例

• 用户侧：注入一个断线的模拟量点，请操作员判断该位置当前有没有可用的读数。
• 实现侧：检查坏值在画面、趋势、报警判断与班报四条路径上的处理是否一致；检查是否存在把坏值静默替换为零或前值的转换环节。

反例做不到——变送器断线后模拟量按协议返回零，画面显示"液位 0%"，随即触发低液位报警，操作员按低液位处置；做过头——把每一个存疑值都做成阻挡视线的醒目标记，正常波动引起的短暂存疑使画面持续闪烁，操作员学会忽略该标记。

依据与参考R17 规定失败状态的结果不得被使用、客户端须在使用前检查状态码，R18 给出可用／存疑／不可用之下的具体状态词汇（含替代值、初始值、无通信时的最后可用值）；R12 §14.3 要求对无效数据给出指示、对未能完成准确性检查的数据标出未验证状态。协议规定的是数据契约，不规定界面如何呈现（见 reference.md R17、R18、R12）。

IH3-3停止刷新的画面不得像正常运行必须¶

一句话：冻结的屏幕是这个领域最危险的一种正常。

适用依赖持续数据更新的监视画面，含工作站、共享大屏与移动终端。

规则当画面与其数据源之间的更新链路中断、画面进程停止响应或显示终端与系统失去联系时，该画面必须以操作员在正常监视距离与正常注意力水平下可察觉的方式表明它已不再更新；这一表明不得依赖操作员主动去核对某个角落的时间戳。产品必须为每类显示终端定义"仍在更新"的判据与其失效的呈现方式，并使该呈现在链路中断时仍可产生——依赖已中断链路才能显示的中断提示不满足本条。无人值守的共享显示同样适用本条。

恢复通信不等于恢复监视。首次连接、重连和服务切换后，必须核对当前值、质量、模式、操作权、活动及未确认报警、干预清单，再按实际同步完成的范围撤除失效标识。旧事件不得覆盖已收到的新状态；重建活动报警清单不等于补齐中断期间历史，历史缺口必须单独标注。恢复期间不自动重发控制指令，不凭缓存恢复控制资格。画面进程本身挂起时，同一进程内的计时器不能承担故障表明；必须有进程外看门狗、独立信号或经验证的替代监视路径。

边界条件本条不要求画面在失联时清空或黑屏；保留最后画面并叠加明确的失效表明是可接受的做法（最后画面上的各个值同时受 IH3-1 约束）。本条不规定察觉方式必须是视觉的，也不规定判定中断的时长。计划内的维护窗口不豁免本条，只是其表明可以附带说明原因。

设计应用把"我还活着"作为显示终端本地可判定的状态，由终端侧的独立机制驱动失效呈现，而不是等待服务端下发一条"你已断线"的消息；对大屏这类无人操作的终端，把失效表明设计成远处可见的形态。

验证示例

• 用户侧：在操作员不知情的条件下切断一台工作站的数据链路，记录从中断到操作员察觉的过程与所依赖的线索。
• 实现侧：分别注入网络中断、服务端停止、画面进程挂起三类故障，确认三类都能产生失效表明；检查失效表明的产生是否依赖被中断的那条链路。

反例做不到——控制室大屏在服务重启后停在两小时前的画面，值班人员整夜都以为装置平稳；做过头——网络抖动一秒就全屏弹出中断遮罩并覆盖操作入口，操作员在真正需要动手时被遮罩挡住。

依据与参考R15 记载伺服液位计卡滞使液位显示“拉平”，且在事故前三个多月内已卡滞 14 次；R18 中“无通信时的最后可用值”是该情形在协议层的既有表达（见 reference.md R15、R18）。

IH3-4强制、旁路与仿真必须显式且可清点必须¶

一句话：谁改的、改成什么、还有几个没恢复。

适用提供点位强制、信号旁路、输出置位、联锁摘除或仿真运行能力的系统。

规则任何改变显示值来源、控制输出或保护关系的人为干预，必须在该值或受影响对象出现的每一处显式标识，标识不得仅存在于工程师站或某一幅专门画面。系统必须提供一份当前全部处于强制、旁路、置位或仿真状态的点位清单，随时可调阅，含执行人、执行时间、原因与预期恢复条件；清单的当前计数应当在操作员的常规视野内可得。禁止提供不进入该清单的干预路径。进入或退出仿真运行模式必须是显式动作并被告知当班人员，仿真状态下的画面必须与真实运行的画面可区分。

边界条件本条不禁止强制与旁路——它们是检修与调试的正当手段；它要求的是这些状态不可隐身。本条不规定清单的复核周期，也不要求系统自动解除强制；自动解除在部分场景下本身就是风险，是否设期限由产品按工艺确定并记录依据。相关报警的抑制另见 IH2-4，动作的留痕与复核另见 IH5-5。

设计应用把干预状态与数据质量（IH3-2）用同一套机制向画面传递，使"这个值是人给的"和"这个值坏了"都无法被静默地当作正常读数；把清单计数放进概览层，使"现在装置上还挂着多少个强制"成为一眼可得的信息。

验证示例

• 用户侧：在若干点位上设置强制后请操作员清点当前被干预的点位数量与位置，比较其结果与系统清单。
• 实现侧：枚举所有能改变点位来源的入口（画面、工程师站、离线组态、调试工具），确认每一个都写入同一份清单。

反例做不到——检修期间旁路的三个联锁信号在复产后无人记得，一个月后事故调查时才在离线配置里被发现；做过头——每个被强制的点位都以持续闪烁的红框呈现，检修期间画面上几十处同时闪烁，操作员把整套标识屏蔽掉。

依据与参考R18 的状态词汇中已含仿真值与本地强制两项，说明这类干预在既有数据契约中即被视为需要单独标识的状态；R15 记载控制室权限设置使所有人员均可更改包括报警设定在内的任何参数。两者均不规定界面如何呈现（见 reference.md R18、R15）。

IH3-5时间与顺序可判定应当¶

一句话：事件的先后是判断因果的前提。

适用记录事件、报警与操作，并可能用于事后分析的系统。

规则事件的时间标记应当能够支持"谁先谁后"的判断：产品应当明确时间标记是在何处产生的（现场设备、控制器还是上位软件），并使参与同一因果链判断的各来源使用可比较的时间基准。当时间基准之间不可比较、时钟未同步或顺序无法判定时，禁止以呈现顺序暗示发生顺序——列表的排列不构成时序结论。时间标记的时区与夏令时处理应当明确，跨班次与跨日的记录应当无歧义。用于首出判别（IH2-5）的顺序信息应当来自具备相应分辨能力的来源，并注明该来源。

边界条件本条不要求全系统达到某一精度的时钟同步——所需分辨率取决于要判断的过程动态，由产品确定并记录依据。本条不要求所有事件都具备顺序判定能力；它要求的是能力边界被说明，而不是被默认具备。

设计应用把时间标记的产生位置作为事件记录的一个字段随事件保存；在事后分析视图里对时间基准不同的记录给出可区分的呈现，不把它们混排成一条看似确定的时间线。

验证示例

• 用户侧：给出一次连锁事件的记录，请两名分析人员独立判断最先发生的是哪一条，比较结论与其依据。
• 实现侧：制造上位软件与控制器之间的时钟偏差，检查事件列表是否仍以排列顺序呈现因果关系而不加说明。

反例做不到——事后分析把所有记录按上位软件接收时刻排序，网络排队使真正的首发事件排在第七位，调查得出错误结论；做过头——为了"顺序绝对可靠"要求全部记录必须携带高精度时间源，不具备条件的事件干脆不记录，反而丢失了大量可用信息。

IH3-6派生值与实测值分别标识应当¶

一句话：算出来的和测出来的不能长成一个样。

适用显示由计算、推断、软测量、统计或模型估计得出的量值的界面。

规则经由计算或估计得出的值应当与直接测量得出的值在呈现上可区分，并应当可取得其计算依据——所用的输入、方法名称与依据、以及在输入缺失或存疑时的行为。派生值禁止以实测值的名义呈现。派生值必须声明其必要输入、冗余或替代规则，以及有效性边界，并据此判定输出质量：必要输入不可用（IH3-2）或已过期（IH3-1）时禁止继续按正常值呈现；存在已验证替代输入且输入合同仍被满足时，可继续按正常值呈现并标注所用输入组合。输入合同未被满足而仍按正常值呈现，是本条的失效。由模型或统计给出的诊断、预测与关联性推断应当与已发生的事实分别标识，并说明其为推断。

边界条件本条不要求把公式展示在画面上；可取得的计算依据可以是一处说明入口。本条不反对使用软测量与推断——它们在缺少直接测量手段时是有价值的；本条要求的是它们的性质不被隐藏。简单的单位换算与量程折算不属于本条所指的派生值。

设计应用把值的来源类型（实测、计算、人工录入、估计）作为数值对象的属性，与质量、时效同层传递；对以推断为基础的诊断结论，把"依据是什么"做成与结论同一入口可达的内容。

验证示例

• 用户侧：请操作员在一幅画面上指出哪些数字是仪表测出来的、哪些是算出来的，比较其判断与实际配置。
• 实现侧：使某个软测量的输入点失效，检查派生值是否随之转入存疑或不可用，而不是以最后一次有效输入继续计算。

反例做不到——一个由三个测点推算出的塔内组分被当作在线分析仪读数使用，其中一个测点已被强制却无人知晓；做过头——每个派生值旁都强制展开完整的计算链与输入清单，操作画面变成公式表，关键数值反而不易定位。

3.4 IH4 控制模式始终在场¶

这条原则管的是设备、回路或装置当前所处的控制模式，以及自动与人工之间的分工。模式混淆是这个领域的经典事故成因：人以为自己在控制而实际上自动在动作，或者以为自动还在工作而它早已退出。它的特点是当事人在犯错的那一刻并不觉得自己在犯错——所有操作都符合他所以为的那个模式下的正确做法。因此本原则不满足于"模式可查"，而要求模式在场：不用询问、不用回忆、不用点开就在视野里。本原则与 IH5 的分界见第 1 章：模式这一状态归 IH4，改变模式这一动作归 IH5。

IH4-1当前控制模式常驻可见必须¶

一句话：不用点开就知道现在谁在控制。

适用受控对象存在一种以上控制模式的系统（手动／自动、就地／远程、级联／串级、维护／运行等）。

规则受控对象的当前控制模式必须与该对象的其他状态同时可见，不得要求操作员额外操作才能得知；模式的呈现必须与该对象在画面上的位置绑定，而不是仅存在于一处集中的模式列表。当一幅画面上提供了对某对象的操作入口时，该对象的当前模式必须在同一视野内可得。模式呈现受 IH1-2 约束：不得仅由颜色区分。模式为未知或不可确定时，必须呈现为未知，禁止呈现为任一具体模式的默认值。

控制来源、控制方式与设备运行状态必须分开解释：就地／远程说明命令来源，手动／自动／串级说明控制方式，运行／停止／跳闸说明设备状态，操作权说明当前谁可下令。它们可同时成立，禁止合成互斥的“就地／远程／自动／停止”菜单。每个维度按受控对象实际能力定义；不支持的维度不强行增加。

边界条件本条不要求每个图元都带一段模式文字；一个稳定的形状或位置约定即可承担。本条不规定模式的划分方式与命名，那由控制系统与工艺决定；但同名模式的语义一致性由 IH4-5 约束。仅有单一控制模式且不可切换的对象记"不适用"。

设计应用把模式与状态做成同一个显示对象的两个属性，使二者不可能分别渲染；对操作面板类界面，把模式呈现放在操作控件的邻近位置，使"我要动它"和"它现在归谁管"在同一次注视中完成。

验证示例

• 用户侧：随机指向画面上的若干受控对象，请操作员在不作任何点击的前提下说出各自当前的控制模式。
• 实现侧：检查是否存在提供操作入口但不显示模式的画面；检查模式未知时的渲染分支。

反例做不到——泵的启停按钮就在画面上，而它是本地还是远程要打开另一幅"控制方式"画面才知道；做过头——每个对象旁边都堆上模式、子模式、投用状态与权限四行文字，画面被状态文字占满，过程信息反而被挤走。

依据与参考R12 §9.4-1 要求以显著的设计特征指示当前模式，并把模式错误描述为“以为系统处于某一模式而实际处于另一模式”所致的不当动作或应做未做；R20 摘要指出在不支持随之而来的认知需求的情况下增加模式数量会产生新的错误形式。R20 本次仅取得摘要（见 reference.md R12、R20）。

IH4-2模式变更可察觉且可追溯必须¶

一句话：它自己掉回手动，也算一次变更。

适用控制模式可能发生变化的系统。

规则控制模式的每一次变化必须可被当班操作员察觉，无论该变化由人发起还是由系统自身发起；系统自发的模式退出（因输入坏值、超限、执行器饱和、通信中断或内部保护而退出自动）必须与人工切换同样被呈现，并且必须可得其原因。每一次模式变更必须被记录，记录含变更时刻、变更前后的模式、发起方（人或系统）与原因；该记录必须可在事后与操作记录、报警记录一同调阅。禁止存在不产生任何呈现与记录的模式变化路径。

边界条件本条不要求每次模式变更都发出报警——是否配置为报警由 IH2-1 与 IH2-3 判定；本条要求的是可察觉与可追溯，一处状态变化加一条事件记录即可满足。本条不规定变更呈现的持续时长。

设计应用把"系统自发退出自动"作为一类需要专门设计的事件，而不是让它复用一般的状态刷新；在设计阶段列出所有可能导致自动退出的条件，逐条确认其呈现方式与原因文本。

验证示例

• 用户侧：使一个处于自动的回路因输入坏值而退出自动，记录操作员是否察觉、以及能否说出退出原因。
• 实现侧：枚举全部可能改变模式的路径（操作员、上位程序、控制器内部逻辑、就地面板、组态下装），确认每条路径都产生呈现与记录。

反例做不到——回路在凌晨因变送器抖动掉回手动，画面上只是一个小标记从"A"变成"M"，没有事件也没有原因，早班接手时输出已经偏了很远；做过头——把每一次正常的批次流程模式切换都做成需要确认的醒目告知，操作员在正常操作中被反复打断，进而对模式变更提示整体失去敏感。

依据与参考R12 §9.4-4 至 §9.4-6 要求对后果重大的模式变更给出提示并要求人工确认、在自动模式变更发生前与发生时分别告知并留出调整时间、并使触发该变更的条件易于取得。该文为核能监管审查导则，其“应”面向审查人员（见 reference.md R12）。

IH4-3自动的作用范围与退出条件可查必须¶

一句话：它在做什么、按什么做、什么时候会撒手。

适用具备自动控制、自动序列、自动优化或自动处置能力的系统。

规则对每一项处于投用状态的自动功能，操作员必须能够取得三件事：它当前作用于哪些对象、它当前依据什么目标或设定值动作、以及在什么条件下它会停止或退出。这三件事必须在自动功能运行期间可得，而不是只写在设计文档或组态里。自动功能有明确的适用边界（工况范围、投用前提、依赖的测点）时，该边界必须可得；当运行状态已接近或超出该边界时，禁止仅以正常运行的方式呈现。多个自动功能同时作用于同一对象时，其相互关系与优先次序必须可得。

自动序列与批次任务必须能查到当前步骤、已完成步骤、下一步转移条件、等待原因及暂停、停止、中止、恢复的区别；界面不能用计时动画虚构进度。更改配方或步骤参数时，必须说明作用于当前批次、未执行步骤还是后续批次，并按 IH5-2 重新核对受影响条件；恢复序列不得默认重做已产生物理效果的步骤。

边界条件本条不要求向操作员展示控制算法或整定参数；"依据什么动作"指的是目标、设定值与约束，不是实现。本条不要求为每个基础回路单独编写说明——同类回路可由统一的约定承担。自动退出之后的状态交接由 IH4-4 约束。

设计应用把"作用范围、当前目标、退出条件"作为自动功能的三项常备信息随其投用状态一起提供；对跨多个回路的高层自动功能（先进控制、自动开停车序列），在概览层给出它当前正在管的范围。

验证示例

• 用户侧：在自动功能运行期间请操作员说出它正在控制哪些对象、目标是什么、什么情况下会退出。
• 实现侧：核对退出条件的说明与控制逻辑中的实际退出判据是否来自同一来源，是否存在只在代码里而未被呈现的退出路径。

反例做不到——一套自动优化功能在后台改动十几个回路的设定值，操作员只能看到设定值在变，不知道是谁在改、按什么改；做过头——把整套控制策略的结构图与全部参数搬到操作画面上，操作员需要读懂控制工程内容才能完成日常监视。

IH4-4接管前给出接管所需的状态必须¶

一句话：交回控制权不等于交回控制。

适用存在自动向人工移交控制的场景的系统。

规则自动功能退出或被切换到人工时，系统必须使操作员能够取得接手所需的状态：当前的输出值或执行器位置、自动退出前的目标与偏差、导致退出的原因，以及此刻处于人工状态下的对象清单。计划内的切换必须无扰动地进行或明示扰动——若切换本身会引起输出跳变，该跳变必须在切换前可预见，禁止以静默跳变的方式移交。由保护、坏值或故障触发的突发退出可能不具备提前告知的时间：此时在不延迟必要保护动作的前提下，必须及时呈现实际输出、退出原因与当前约束，并使此类退出的可能性与移交方式在事前可查；禁止以"界面已明示"使本不允许的危险输出跳变成为合法——输出跳变本身的限制由控制与工艺安全的相应约定决定，不由界面措辞决定。当移交发生在异常工况中时，系统应当同时给出该对象当前受哪些约束（联锁状态、限位、其他自动功能的作用）。移交完成不得仅以模式标记的改变表示。

边界条件本条不要求系统给出处置建议——给出建议属于 IH2-6 的范围，且不得替代规程。本条不规定移交所需信息的呈现形式，也不要求为每一次常规的手自动切换都提供完整交接信息；异常工况下的移交是本条的重点适用场景。

设计应用把"退出自动"这一事件设计成一次交接而不是一次状态跳变：退出的同时把原因、当前输出、偏差与约束集中到操作员正在看的位置；对可能在异常中退出的自动功能，预先设计其退出时的呈现。

验证示例

• 用户侧：在一次带偏差的工况中触发自动退出，记录操作员判断"现在该怎么办"所需的信息是否都已在手边，以及是否需要另开画面查找。
• 实现侧：检查计划内手自动切换是否存在输出跳变的路径、跳变前是否有可预见的提示；对突发退出，检查告知机制是否会延迟必要的保护动作，以及退出后实际输出与原因是否及时可得。

反例做不到——先进控制在夜间因某个测点存疑而整体退出，回路落回手动，各阀位停在退出瞬间的开度上，操作员第二天早上才发现塔一直在偏；做过头——每次退出自动都强制弹出一页需要逐项确认的交接清单，操作员在需要立刻调阀时先被清单挡住。

依据与参考R19 论述长期监视自动过程会使技能退化，而需要接管时反而要求更高的技能与更低的负荷；R12 §9.4-3 要求说明新模式如何改变自动化的运作、对装置的影响与操作员职责。R19 是 1983 年的论述性综述，不是实证研究（见 reference.md R19、R12）。

IH4-5同名模式在各处语义一致必须¶

一句话：两个画面上的"手动"必须是同一件事。

适用由多个子系统、多个厂商设备或多代画面组成的系统。

规则同一名称的控制模式在整个操作员可见范围内必须指同一件事；当不同子系统的同名模式实际语义不同时，禁止沿用同一名称呈现给操作员——必须改名、加限定或在呈现上明确区分。模式名称、其含义与其对操作的影响必须有一份统一的来源，并被各画面引用；新接入的子系统必须完成模式语义的对照，不得直接沿用其自带的模式命名。就地面板与上位画面上的同一对象，其模式呈现必须一致或其差异被明确说明。

边界条件本条不要求统一各厂商设备内部的模式实现，也不要求各子系统改造其控制逻辑；它要求的是呈现给操作员的名称与语义一致。本条不规定命名方式。

设计应用在集成新子系统时把"模式对照"列为固定的交付项，逐项确认每个模式名在本装置语境下的含义；把模式定义放在一处集中维护，画面从中取值而不是各自写死文字。

验证示例

• 用户侧：跨两个来源不同的子系统各取一个标为同一模式名的对象，请操作员说明这两个对象此刻分别由谁控制、自己能做什么，比较其回答与实际。
• 实现侧：清点全系统出现过的模式名称与其定义来源，找出同名异义与异名同义的条目。

反例做不到——A 厂商的"远程"指由上位机控制，B 厂商的"远程"指由就地控制柜控制，两者在同一幅画面上并排显示；做过头——为了绝对精确把模式名改成一串带子系统前缀的长编码，操作员在紧急时读不出它的实际含义。

IH4-6自动不得静默补偿掩盖异常应当¶

一句话：阀已经开到头了，这件事要说出来。

适用具备闭环控制、自动调节或自动补偿能力的系统。

规则自动控制在维持被控量的过程中会吸收扰动，这一过程本身可能掩盖正在恶化的设备或工艺状况。产品应当使这类被自动吸收的偏离可被察觉：执行器接近或到达行程极限、控制输出长期单向漂移、为维持同一目标所需的操作量持续增大、以及自动功能反复触发同一项补偿——这几类情况应当被识别并呈现，不应当只体现为"被控量一直很稳"。禁止在自动功能已无余量继续补偿时仍以正常运行的方式呈现该对象。是否将上述情况配置为报警按 IH2-1 与 IH2-3 判定，本条不预设。

边界条件本条不要求系统作出故障诊断结论——识别出"操作量在持续增大"是事实呈现，判断"这是换热器结垢"是诊断，后者若给出须按 IH3-6 标识为推断。本条不规定判定"持续""接近极限"的具体数值与窗口，由产品按设备特性确定并记录依据。

设计应用把执行器余量作为与被控量同等重要的一项可视信息，而不是只在诊断画面里可查；对关键回路，把"维持当前目标所需的操作量"纳入常规趋势观察对象。

验证示例

• 用户侧：模拟一个缓慢发展的阻力增大过程，被控量始终在正常范围内，记录操作员能否在执行器到达极限之前察觉。
• 实现侧：检查执行器饱和、输出单向漂移等状态是否被采集并呈现，还是仅在退出自动时才第一次出现。

反例做不到——温度显示八个月都很平稳，直到调节阀彻底开到 100% 无法再补偿，装置在几分钟内失控；做过头——把每一次正常的调节动作都做成"自动正在补偿"的提示，画面上持续滚动补偿信息，真正的余量耗尽被淹没其中。

3.5 IH5 操作有授权、有核对、有痕迹¶

这条原则管的是操作员经由界面发出的控制动作。工业 HMI 上的一次点击可能启动一台泵、打开一路进料、复位一次联锁——它的后果不由撤销按钮承担，因此这里的设计重点不是"能不能改回来"，而是在动作发出之前把对象与后果核对清楚，在动作发出之后留下可被追查的痕迹。同时必须划清一条界线：界面上的确认是给人用的核对手段，不是安全措施——它拦不住的东西，要靠联锁与安全功能拦。本原则与 IH4 的分界见第 1 章。

IH5-1关键操作采用选择—核对—执行必须¶

一句话：先看清楚点中了谁，再动手。

适用可经由界面发出控制指令的系统中，后果达到产品所定义关键等级的操作。

规则关键操作必须由选择对象、核对对象与拟执行动作、发出执行三个可分辨的步骤构成；选择之后、执行之前，当前选中的对象与将要执行的动作必须明确可见，禁止一次点击即发出关键指令。选中状态必须与执行动作在同一视野内可核对，且禁止在选中状态下由界面自动切换选中对象。产品必须定义哪些操作属于关键等级，并记录其判据；判据依据后果，不依据操作频次。

每一类控制动作的语义与结束条件必须被显式定义并在界面上可分辨：普通停止、紧急停止请求、故障复位、启动、以及连续操纵（点动、按住运行、连续调节）各自改变什么、其执行结果如何确认、以及在失去焦点、手指释放、连接中断或终端锁屏时如何结束。连续操纵在输入中断时必须按其定义的结束方式停止，禁止因界面失联而保持在继续动作的状态。紧急停止请求禁止被通用的多步确认机械延迟；确认不等于能源已隔离，复位不等于允许重新启动，三者在界面上必须分别表达。

触摸与连续操纵必须按现场输入条件验证：手套、湿手、振动、误触邻近目标、拖出热区、多点触摸及键盘长按分别考虑；关键控制不能只靠悬停或隐蔽手势发现。按住运行必须有控制侧可执行的释放或失联结束机制，不能只靠浏览器发送一次松开事件。普通确认、会话锁定或遮罩不得阻断已分配的必要紧急停止路径。

边界条件紧急停止请求按其动作合同处理，不受普通关键操作的通用三步确认约束。本条不要求所有操作都走三步——高频的常规调整（如小幅改设定值）走三步会使操作变形，是否纳入按后果判定。本条不规定停止、复位与启动在某一设备上的具体物理含义与时序，那由该设备的控制与安全约定决定；本条要求的是这些含义被写下来并在界面上不被混同。本条也不给出触屏、手套操作或移动弱网条件下的通用尺寸与时长数值——这些条件下的任务范围与允许动作由产品按现场记录。本条不规定三步必须由三次点击完成；一次拖动加一次确认动作也可构成核对与执行，只要核对环节实际存在且对象可见。本条不涉及确认对话的内容，那是 IH5-2。

设计应用把选中作为一个持续可见的产品状态而不是一次瞬时高亮；在执行控件上呈现"对哪个对象做什么"，使核对不需要在两处之间来回移动视线。

验证示例

• 用户侧：在密集布置的画面上要求操作员对指定设备执行一次关键操作，记录其在执行前是否确认了对象、以及是否发生过误选。
• 实现侧：清点全部关键操作入口，确认不存在单次点击直达执行的路径，包括快捷键、右键菜单与触摸手势。

反例做不到——工艺流程图上密集排列的阀门图元点一下就动作，操作员在触摸屏上误触相邻阀；做过头——把改一个设定值也做成三步确认，操作员在需要连续微调时逐次点确认，改为在旁路系统上直接改值。

IH5-2确认承载后果而不只是问一句必须¶

一句话："确定吗"不是确认，是一次多余的点击。

适用为操作设置确认环节的系统。

规则确认环节必须承载这一次操作的具体信息：对象、动作、当前状态与执行后的预期状态，以及在当前工况下已知的后果或前提不满足项；禁止使用不含操作对象与后果的通用确认。当执行的前提条件不满足（联锁未复位、上游未就绪、权限不足、对象处于不允许该操作的模式）时，确认环节必须说明该情况，禁止让操作员确认一个必然失败的操作。确认环节的存在不得成为省略前置校验的理由。同一操作在短时间内反复要求确认而内容不变时，该确认已失去核对作用，产品应当重新评估其设置。

预检不替代执行前复核。确认前呈现的是当时可取得的前提及其时效；指令被受理并将产生作用之前，控制系统必须按权威状态再次验证权限、模式、联锁与动作条件。关键对象、参数或后果在确认框打开之后发生变化的，旧的核对即失效，必须重新核对而不得凭过期条件继续授权。只能在执行时刻才能确定的条件必须说明该限制，禁止把它伪装为确认前已验证。

边界条件本条不要求确认必须是一个对话框；就地展开、二次按压、双键并发都可以承担确认。本条不要求列出全部可能后果——要求的是列出这一次已知的关键信息，而不是一段通用警示文本。本条不规定确认的输入方式。

设计应用把确认内容由操作请求本身生成，而不是写成静态文案；把前置条件校验放在确认之前执行，使确认环节能够呈现校验结果，同时在受理侧保留一次执行前复核——两者各自回答不同的问题："现在能不能做"与"这一刻仍然能不能做"。把"什么变化会使旧核对失效"写成显式清单，而不是靠确认框的存续时间推测。

验证示例

• 用户侧：请操作员在确认环节出现时说出即将发生什么、对谁发生；说不出即为本条未落实。
• 实现侧：抽查确认文案，统计其中不含对象与动作的通用文案比例；检查前置条件校验与确认的先后次序，以及受理侧是否存在独立的执行前复核。构造"确认后权限被收回""确认后就地接管""确认后联锁状态变化"三种情形，核对指令是否被拦下而不是按旧条件执行。

反例做不到——所有操作共用一句"确定要执行此操作吗？"，操作员形成条件反射式点击；做过头——每次确认都罗列十几条可能后果与免责说明，操作员直接跳到确认按钮，阅读量的增加没有换来核对质量的提高。

IH5-3普通确认不构成安全功能的实现证据必须¶

一句话：弹窗拦不住的东西，要靠别的东西拦。

适用全部工业 HMI。

规则普通的 HMI 确认、提示、警告与界面权限展示本身不构成安全功能的实现证据；产品禁止仅凭"界面已提示""操作员已确认"降低、延后或取消适用的联锁与保护措施。凡拟把风险降低职责赋予报警、操作员响应、访问控制或其他 HMI 相关机制的，必须由适用的安全生命周期明确其职责分配、独立性、性能要求、人因要求与验证要求；本规范既不授予也不核定该保护信用，也不否认此类分配的可能性。当界面提供的操作可能与联锁或保护发生交互（复位、旁路、抑制、强制、允许越权执行）时，界面必须如实呈现该交互的性质与当前保护状态，禁止把旁路或摘除呈现为一次普通操作；界面必须如实区分普通控制、保护状态、旁路、复位与重新启动，并呈现其真实能力边界。未被安全生命周期分配职责的界面机制被绕过或失效时，其结果必须落在安全侧的机制上，而不是落在操作员的判断上。

边界条件本条不禁止界面设置确认与提示——它们对减少误操作有价值；本条禁止的是在没有专项分配与验证的情况下把它们计入保护。本条不作任何功能安全等级的判定，不规定联锁与保护的设计与验证，也不预先否定安全生命周期可能分配给报警系统或操作员响应的风险降低职责——该分配是否成立、成立到什么程度，由适用的功能安全标准体系判定，不由本规范判定（见范围声明与附录 B）。

设计应用在设计评审中对每一项"靠界面拦住"的危险动作追问"如果这次点击照样发生了会怎样"，答案落在人身或设备后果上的，说明该动作需要界面之外的保护；把界面确认写进设计文档时明确标注其为人因辅助措施而非保护措施。

验证示例

• 用户侧：对普通确认构造一次误确认，检查相关保护是否仍按已批准的设计执行。
• 实现侧：核对危险动作清单，逐项确认其阻止机制不只存在于界面层；检查是否有以界面提示为由被取消的保护项；对声称承担安全职责的界面机制，只核查是否存在专项的职责分配与验证证据引用，不由界面评审代替安全评估，也不以"含有认证部件"替代整条功能的验证。

反例做不到——防止两台设备同时启动的约束只写在画面逻辑里，绕过画面用工程师站或就地面板即可同时启动；做过头——把所有联锁的复位入口都从操作画面移走以求"界面绝不参与安全"，操作员在需要正常复位时被迫使用非常规路径，反而增加了绕过行为。

依据与参考R15 记载罐区模拟图上显示了一个红色紧急停车按钮，而多名值班人员并不知道它从未接入系统。这是界面上的控件不构成保护的一次公开失效记录；本条其余部分由承诺反推，不引用任何功能安全标准（见 reference.md R15 与附录 B.3）。

IH5-4权限与值班角色由机制强制必须¶

一句话：权限不是把按钮藏起来。

适用区分操作权限、值班角色或工位职责的系统。

规则操作权限必须在指令被受理的一侧强制，而不是仅由界面的显示与隐藏实现；经由其他入口（工程师站、组态工具、脚本、接口调用、就地面板）发出的同一指令必须受同一套权限约束。权限不足时界面必须说明当前不可执行以及需要什么条件，而不是让控件静默失效或凭空消失。值班身份必须是可确定的：系统必须能够对每一次操作解析到发出它的值班身份，禁止以长期共享且无法区分个人的通用账户作为承担关键操作留痕的唯一方式。临时提权必须有范围、有期限、有记录，并在到期后自动收回。

边界条件本条不规定认证方式，也不要求每次操作都重新认证——控制室的物理准入与工位登录在多数场所是合理的组合。本条不处理工控网络安全的认证与访问控制要求，那须按适用的网络安全标准另行评估（见范围声明）。本条不禁止共享工位，禁止的是共享工位使操作无法归属。

设计应用把权限判定放在指令受理侧并由所有入口共用；把值班身份与工位登录绑定，使交接班时的身份切换是一个显式动作而不是一次可选操作。

验证示例

• 用户侧：以低权限身份尝试关键操作，检查界面是否说明缺少什么条件；以另一入口发出同一指令，检查是否同样被拒绝。
• 实现侧：清点全部可发出控制指令的入口，逐个验证权限判定是否生效；抽查操作记录中无法解析到具体个人的比例。

反例做不到——画面上按权限隐藏了按钮，而同一条指令通过工程师站的调试工具可以直接下发且不留身份；做过头——把权限切得极细并要求每次跨类操作重新登录，操作员为了在处置中不被打断而长期共用一个高权限账号登录。

依据与参考R15 记载控制室的权限设置使所有值班人员均可更改任意参数，包括报警设定。本条不处理工控网络安全的访问控制要求，那须按适用标准另行评估（见 reference.md R15 与规范范围声明）。

IH5-5旁路、强制与越权留痕并被复核必须¶

一句话：高后果动作留下的记录，要有人真的去看。

适用提供旁路、强制、联锁摘除、报警屏蔽、越权执行或参数越限设置能力的系统。

规则上述高后果动作必须留下记录，含执行人、时刻、对象、动作前后的值或状态、原因，以及预期的恢复条件；原因不得以空值或系统默认文本填充。记录必须不可由执行者本人静默删除或改写，并可被独立调阅。产品必须定义这些记录的复核责任与复核时机——记录无人查看时，留痕不产生任何作用；复核结果与未恢复项必须能够进入交接班（IH6-3）。当前仍处于生效状态的旁路与强制同时受 IH3-4 的清单要求约束：记录管"发生过什么"，清单管"现在还挂着什么"，两者不互相替代。

边界条件本条不规定记录的保存期限与复核周期，由产品按工艺后果与适用要求确定并记录依据。本条不要求复核由专人专岗承担，但要求责任可解析到具体角色。本条不作合规性判定。

设计应用把"原因"做成必填且有可选类目的结构化字段而不是自由文本框，使事后可按类目统计；把"当前未恢复的高后果动作"作为固定的复核入口与交接项，而不是等待有人主动去翻日志。

验证示例

• 用户侧：调阅最近一段时期的高后果动作记录，检查是否存在原因缺失项、是否存在长期未恢复项、是否有复核痕迹。
• 实现侧：尝试从执行者的账户删除或修改一条自己的记录；检查是否存在不写记录的旁路路径。

反例做不到——联锁摘除只在控制器里改了一个位，系统中没有任何记录，交接班无人提及；做过头——把留痕做成需要逐级审批的表单流程，操作员在紧急处置中无法及时旁路，转而请人在控制器里直接改，记录反而彻底消失。

IH5-6指令结果可核对，并发操作有裁决必须¶

一句话：两个人同时动同一台泵，裁决要明确，两边看到的结果不能都说"成功"。

适用经界面发出控制指令的系统；并发裁决额外适用于同一对象可被多个入口操作的情形，包括控制室、就地面板、移动终端与远程入口。

规则对同一受控对象的并发操作必须有明确的裁决规则，且该规则必须对参与各方可见：谁当前持有该对象的操作权、其他方此刻能做什么、操作权如何取得与释放。禁止出现两个入口各自认为自己的指令已生效而实际只有一个生效的情况——被拒绝或被覆盖的一方必须收到明确结果。当一方的操作被另一方接管或覆盖时，原操作方必须被告知。就地操作与远程操作之间的优先关系必须明确并在两侧一致呈现（另见 IH4-5）。

指令提交或受理、控制器执行结果、设备反馈、以及预期的过程效果必须分别表达，证据不足时保留"待核对"或"结果未知"，禁止以其中任一项冒充其余三项——协议层写入成功不等于阀门到位，阀门到位不等于流量改变。通信超时本身不足以证明动作未发生。可能重复产生物理效果的指令（点动、加料、累计增量、启停），在核对到状态或具备经验证的防重保障之前禁止自动重发；重连、切换工位与控制器重启都不构成重新执行的授权。

边界条件本条不规定采用何种裁决方式（排他持有、优先级、先到先得均可），也不要求所有对象都设置操作权归属——低后果对象可不设，但必须有受理侧的冲突裁决与明确结果，由产品按后果确定并记录依据。本条不要求并发的两条指令中只有一条曾被执行：受理侧按已声明的裁决串行处理、先执行启动随后执行更高优先级的停止，两条都真实发生并不违反本条；本条要求的是裁决明确、各方结果可分辨、最终状态不被误述。本条不处理网络层的并发一致性实现。

设计应用把操作权归属作为受控对象的一项可见状态，与控制模式（IH4-1）同层呈现；在移动巡检终端与控制室工位之间明确"现场优先"或"控制室优先"的规则，并让两侧都看到当前归属。

验证示例

• 用户侧：安排两名操作员从不同工位在同一时间对同一对象发出相反指令，记录两侧各自看到的结果与实际发生的动作。
• 实现侧：检查指令受理侧是否存在裁决逻辑，还是仅由界面互斥；检查被拒指令是否向发起方返回明确结果。另构造"控制器受理但执行器卡住""中间系统返回异步成功""动作已执行但回执丢失""断线重连后重复点击"四种情形，核对实际动作次数与界面所述结果是否一致，而不只检查按钮是否置灰。

反例做不到——控制室下发停泵、现场同时按了启动，两侧界面都显示操作成功，泵的实际状态与两人的认知都不一致；做过头——为避免冲突把对象锁定期设得很长且无法强制释放，一名操作员离开工位后其他人无法接管，处置被一把锁挡住。

3.6 IH6 值班是连续的¶

这条原则管的是跨时间、跨人、跨工位的值班过程本身。前五条原则的规范对象都在一个时刻之内：这个值现在怎么呈现、这条报警现在该不该发、这次操作现在怎么核对。但操作员面对的过程不在一个时刻之内结束——一件事可能跨越三个班次，一个人的判断依赖于他不在场时发生过什么，一块大屏和一台工作站要分工而不是互相复制。把界面设计成"一个人在一个时刻面对一幅画面"，是这个领域的一处系统性缺口：它使交接班退化为口头传递，使深夜的监视依赖个人警觉，使一次改版在别人值班时悄然生效。本原则的对象是这段连续过程。

IH6-1钻取与返回不丢失情境必须¶

一句话：点进去看细节，不该迷路。

适用由概览、区域与设备等多层画面构成的系统。

规则从一层画面进入下一层时，进入的依据必须被带入：从概览上的某个异常区域进入，到达的画面必须指向该区域及引发进入的那个对象，禁止跳转到一幅与进入依据无关的通用画面。返回时必须回到原来的位置与原来的观察状态（所处画面、时间范围、筛选条件、被关注的对象），而不是回到默认首页。当前所处的位置与它在整体中的层级必须可得，禁止要求操作员靠记忆维持自己在画面结构中的位置。跨画面的时间范围与筛选条件在同一次分析过程中应当保持一致，改变时应当明示。

边界条件本条不规定导航的实现形式（层级树、返回栈、面包屑、并排视图均可），也不要求任意两幅画面之间都可直达。本条不处理画面层级本身的划分，那是 IH1-5。工作状态跨班次的延续见 IH6-6。

设计应用把"当前观察情境"（对象、时间范围、筛选）做成一个可随导航传递的对象，而不是每幅画面各自维护自己的默认值；从报警条目进入时把该条报警作为进入依据传下去，使目标画面直接指向相关对象。

验证示例

• 用户侧：从概览的一处异常连续钻取三层再返回，记录返回后是否需要重新设置时间范围与筛选条件。
• 实现侧：清点跳转入口，检查是否存在丢弃进入依据、跳转到通用画面的路径。

反例做不到——点击报警只是打开了该设备所属的整幅工艺画面，操作员还要在几十个图元里自己找是哪一个；做过头——每次跳转都携带并叠加上一层的全部筛选条件，操作员在第三层看到的是被层层过滤后的空画面，且不清楚被过滤掉了什么。

IH6-2共享显示与个人工位分工明确应当¶

一句话：大屏不是把工作站画面放大。

适用同时存在共享显示（控制室大屏、班组看板）与个人工作站的场所。

规则共享显示与个人工位应当承担不同的职责并各自声明：共享显示服务于班组共同持有的情境——整体是否正常、异常在哪、当前有哪些正在进行的处置；个人工位服务于当前这个人正在做的事。共享显示上禁止呈现只有坐在特定工位才读得懂或读得清的内容，其可读性应当按实际观看距离与角度验证，而不是按工作站的观看条件设计。共享显示的内容不应当由某一个人的操作随意改变；确需切换时，切换应当对在场人员可见并可回到默认。共享显示同样受 IH3-3 约束：它停止刷新时必须可察觉。

边界条件本条不要求必须配置共享显示；无共享显示的场所记"不适用"。本条不规定大屏的画面数量与布局。移动巡检终端与控制室工位之间的分工不属于本条，其操作裁决见 IH5-6。

设计应用先写出"班组需要共同看到什么"，再决定大屏画什么；把大屏内容设计成不需要交互即成立的呈现，而不是一个被放大的可操作界面。

验证示例

• 用户侧：在实际观看位置上请班组成员读出大屏的关键信息，记录读错与读不出的项。
• 实现侧：核对大屏内容是否有声明的职责、是否按实际观看条件验证过可读性、停止刷新时是否可察觉。内容与某一工作站画面相同不单独构成违例——职责、可读性与状态连续性才是本条的判据。

反例做不到——大屏就是把一台工作站的画面投上去，坐在后排的人只能看到一片色块，班组的共同情境实际不存在；做过头——大屏被做成一套需要遥控操作的独立系统，异常时无人愿意起身操作，它长期停留在一幅无关画面上。

IH6-3交接班有可核验的交接对象必须¶

一句话：交班交的是未完成的事，不是一句"正常"。

适用连续值班、存在班次交接的场所。

规则系统必须能够生成一份可核验的交接对象清单，至少覆盖：当前处于抑制或搁置状态的报警（IH2-4）、当前处于强制、旁路或仿真状态的点位（IH3-4）、当前处于非正常控制模式的对象（IH4-1）、本班内发生的高后果动作及其未恢复项（IH5-5），以及未完成的异常处置（IH6-6）。交接必须是双方的显式动作：接班方确认接收，交接时刻与双方身份被记录。禁止把交接清单退化为一段自由文本备注——备注可以存在，但不替代上述可核验项。交接清单中的每一项必须可追溯到其来源状态，而不是一次性快照文本。

签收必须对应实际核对内容：记录本次交接核对的条目集合和时刻，同时保留到当前来源状态的链接。核对期间新增或变化的旁路、报警、操作权及待核对指令必须作为差异提示给接班方，不能由一次旧签收自动覆盖。责任移交与操作权转移分别确认；拒收、超时或中断不能把事项变成无人负责，也不能把浏览清单当作接班完成。

边界条件本条不规定交接的组织形式与时长，也不要求系统替代口头交接——口头交接传递的判断与预期是清单无法承载的，本条要求的是清单不缺项。本条不规定清单项的排序与呈现方式。

设计应用把交接清单由当前系统状态实时生成而不是由人手工整理；对每一项提供进入其详情的入口，使接班方可以就地核对而不是只读一行摘要。

验证示例

• 用户侧：在存在若干项搁置报警与强制点位的状态下完成一次交接，检查接班方能否在清单上找到全部项并逐项核对。
• 实现侧：分别制造五类交接项，确认每一类都自动进入清单；检查是否存在只在口头传递而系统不可见的状态类别。

反例做不到——交接记录只有"运行正常"四个字，上一班搁置的两条报警和一个未恢复的旁路在两个班次之后才被发现；做过头——清单把本班全部事件逐条列入，交接时要翻过几百条记录，接班方对清单整体略过。

IH6-4长时间监视不依赖持续警觉应当¶

一句话：别指望人盯着一块不动的屏幕八小时。

适用以持续监视为主要任务、长时间无事件发生的值班岗位。

规则产品不应当把"操作员会持续注意到画面上的细微变化"作为设计前提。对需要被察觉的偏离，产品应当提供不依赖持续注视的察觉路径（IH1-1 的强度分配、IH2 的报警通道、或其他主动呈现方式）；禁止把仅由数值缓慢变化承载的关键偏离作为唯一的察觉手段。产品应当使操作员能够在离开与返回之间取得"我不在的这段时间发生了什么"——返回时可得该时段内的状态变化、报警与操作。夜班、长班次与低事件率场景应当被纳入设计与验证的情境，而不是只按白班的注意力水平设计。禁止以强制交互（定时点击、周期性应答）作为维持警觉的唯一手段并据此认为本条已满足。

边界条件本条不禁止使用值班应答类机制——在部分场所它有其作用；本条禁止的是以它替代可察觉的呈现设计。本条不规定班次安排、休息制度与人员配置，那属于场所的运行管理与工效学范围（见范围声明）。本条不给出注意力衰减的时间数值。

设计应用对每一类需要被察觉的偏离，明确写出"它靠什么被察觉"，答案是"操作员会看到"的，重新设计；把"离开期间发生了什么"做成一个可得的时段回顾，而不要求操作员翻阅完整历史。

验证示例

• 用户侧：在低事件率的长时段中注入一处缓慢发展的偏离，记录察觉时间与所依赖的线索。
• 实现侧：清点需要被察觉的偏离类别，逐项确认其察觉路径不是"持续注视数值"。

反例做不到——某个缓慢上升的液位没有配置任何限值，设计上认为操作员看趋势就会发现，实际连续三班无人察觉；做过头——每十五分钟弹出一次必须点击的在岗确认，操作员形成机械应答，真正需要响应时同样机械地点掉。

依据与参考R19 援引警觉研究指出人难以对极少发生变化的信息源长时间维持有效的视觉注意，并指出“人可以抄下数字而不注意其含义”；R09 说明操作员须在长班次中监视低频事件；R23 报告警觉衰减随任务时长呈线性成分的可测量下降。R23 为实验室抽象任务研究，不是控制室研究，本规范据此不给出任何时长数值（见 reference.md R19、R09、R23）。

IH6-5值班期间的界面与配置变更受控应当¶

一句话：不在别人值班时悄悄换掉画面。

适用画面、报警配置、限值、权限与自动功能可在运行期间被修改的系统。

规则影响操作员判断与操作方式的变更——画面布局与图元含义、报警的增删与限值调整、优先级重定级、权限变化、自动功能的投用范围变化——应当在生效前被当班人员知晓，并可得变更内容与生效时刻。禁止在操作员正在处置异常期间静默改变其正在使用的画面语义或操作入口位置。变更应当留下记录并可追溯到发起人；变更后应当可确认操作员已知晓，尤其是跨班次生效的变更（另见 IH6-3）。变更不得使正在进行中的处置失去其原有入口。回退路径应当存在并可在值班期间执行。

边界条件本条不要求所有变更都提前通知——纠正一处明显错误的即时修复可以先执行后告知，但仍须留痕并被告知。本条不规定变更管理的组织流程与审批层级，那属于场所的管理体系。

设计应用把"变更影响哪些画面、哪些报警、哪些操作入口"作为变更提交时的必填内容，由系统据此生成对当班人员的告知；展示变更影响与生效时刻，使操作员能判断当前画面有哪些变化。

验证示例

• 用户侧：在一次跨班次生效的报警限值调整后，询问接班操作员是否知晓该调整及其内容。
• 实现侧：检查是否存在不产生记录与告知的配置修改路径（工程师站直改、离线组态下装、脚本批量修改）。

反例做不到——工程人员在白班调整了几十条报警的限值并直接下装，夜班操作员发现报警行为变了却不知道发生过什么；做过头——把每一处文字修正都做成需要全员确认的变更告知，操作员对变更告知整体麻木，真正影响判断的那次改动同样被略过。

IH6-6异常处置的工作状态可延续必须¶

一句话：一件事没处理完就下班了，它得有个去处。

适用存在可能跨越单次值守时段的异常处置、诊断或跟踪任务的系统。

规则一次未完成的异常处置必须能够作为一个有状态的对象被延续，而不是随着操作员离开工位而消失。该对象必须至少可得：它对应的异常、当前处于什么阶段、已经做过什么、正在等待什么、以及由谁负责。它必须能够进入交接清单（IH6-3），并在接班方接手后保持连续，禁止要求接班方从原始记录中重建处置过程。当处置涉及被搁置的报警、被旁路的信号或被强制的点位时，这些项必须与该处置对象关联，使其恢复条件不依赖个人记忆。

边界条件本条不要求系统承担工单、检维修与作业许可等既有管理系统的职责——已有相应系统时，本条要求的是处置状态与其中的关联项可得且不丢失，可由既有系统承担。本条不规定处置对象的阶段划分与命名。本条不要求为每一次小的异常都建立处置对象，纳入范围由产品按后果与持续时长确定并记录依据。

设计应用把"正在处置中的异常"做成与报警清单并列的一份可见清单，而不是散落在各人的记录本里；把搁置、旁路与强制的恢复条件挂到对应的处置对象上，使处置结束时能够一并核对。

验证示例

• 用户侧：在一次尚未结束的处置中执行交接，记录接班方掌握当前进展所需的时间与是否需要电话询问上一班。
• 实现侧：检查处置对象是否与其关联的搁置项、旁路项保持链接；检查处置对象在工位登出与系统重启后是否仍然存在。

反例做不到——夜班对一台机泵振动升高的跟踪只记在个人本子上，交班时口头带过，白班重新从零开始判断；做过头——要求每一次微小异常都建立完整的处置记录并逐阶段填写，操作员在忙时放弃使用该机制，真正需要延续的那次处置同样没有被记录。

4. 术语和定义¶

本章只定义本规范内使用且容易产生歧义的词。控制工程与功能安全的专业术语以适用的标准与规程的定义为准，本章的说明只用于理解本规范条款，不构成对这些术语的重新定义。

5. 从设计决定到验收证据¶

5.1 最小交付记录¶

每个项目按实际能力完成下列记录。填写 Token 只证明决定已记录，不能证明控制机制或操作员表现已经通过验证。

设计必须覆盖声明范围内的正常工况、开停车、异常、维护、失联恢复及交接；不支持的任务明确排除，不能只展示正常运行画面便宣称覆盖完整岗位。

5.2 分开验证三类事实¶

每条用例至少记录：对象与工况、故障或触发、实际输入、预期及实际结果、开始与结束的测量事件、误操作或遗漏、证据位置、判定人。察觉时间从异常在权威来源成立起计，并分别记录采集、传输、呈现与人的响应耗时；不能只从弹窗出现时计时而忽略前面的延迟。

5.3 门槛不能互相抵消¶

1. 禁止行为：坏值冒充实时正常、未授权关键指令生效、结果未知后重复动作、旧确认覆盖新报警、失联时连续操纵不结束。声明适用范围的测试中出现任一项即不通过，其他指标不能抵消。
2. 任务表现：定位异常、理解模式、识别对象、完成正确动作的成功率与耗时。项目在测试前写明目标、样本和理由；漏处置与错误目标选择单列，不能隐藏在平均耗时内。
3. 响应时间：报警检测与传输、呈现、人员判断与动作、必要的设备及过程响应，总耗时须在可用响应窗口内并保留有依据的余量。若无法做到，调整职责分配、控制或保护设计，不能仅靠提高声音与颜色强度。
4. 持续运行：值班负荷、重复报警、超时待核对指令、长期干预与未交接事项有负责人和后续处置，故障恢复路径实际可用。

结论分为“通过声明范围”“受限使用”“不通过”。受限使用必须说明真实限制及替代保障，例如只读终端且另有已验证的控制与报警路径；不能以关闭必要报警、清空已有干预或让操作员凭记忆监视来制造通过条件。现役系统不得因一份配置检查失败就自动停机、停用保护或抹掉运行状态。

5.4 同时检查遗漏与过度设计¶

异常要可发现，也测正常状态是否安静可读；关键动作要能核对，也测常规微调是否被重复确认拖慢；冻结画面要有提示，也测提示是否挡住仍有效的处置入口；交接要完整，也测关键差异能否从普通记录中被找到。代表性任务或环境条件变化时，重新检查受影响的证据；实际漏报、误触、接管失败与未恢复干预进入后续验证场景。

附录 A：故障注入验证清单与分类检验¶

本清单用于检验条款是否真的生效，不新增义务。逐项注入，记录系统的实际行为；记录"不适用"是合格结果，记录"没测"不是。注入试验须在不影响实际生产与人员安全的条件下进行——在仿真环境、备用系统或经批准的停车窗口内执行，本附录不构成在运行装置上开展这些试验的依据。

A.1 呈现与可读

A.2 报警

A.3 数据可信

A.4 模式与接管

A.5 操作与授权

A.6 值班连续性

A.7 组合故障与完整任务

A.8 分类检验

用于检验第 1 章的切分是否成立：取 10 至 15 条具体要求（可来自本规范条款，也可来自真实评审意见与事件调查结论），让至少三名未参与撰写的评审者独立判断其归属原则。归属分歧集中在某两条原则之间，说明这两条原则的规范对象没有切开——此时应当调整原则，而不是增设中间层或映射说明。已知需要重点检验的两处见第 1 章的明示（IH1 与 IH3、IH4 与 IH5）。评审人数与分歧判据是本规范建议的内部检查法，不是经过文献验证的标准方法。

附录 B：论据边界与来源类型¶

B.1 约束词的判据

标「必须」的唯一依据是：缺了它，某条对操作员的承诺会在可预见的情境下失效。下列三类论据提供不同支持，不是三种独立的强制性来源；行业标准的存在或某个产品这样做过，本身都不足以决定标「必须」——

标「应当」的八条（IH1-4、IH2-6、IH3-5、IH3-6、IH4-6、IH6-2、IH6-4、IH6-5）都是取舍问题而非底线问题：偏离可能有正当理由，但要留痕并接受同样的验证。其中若干条含禁止级子句（见 2.2），子句本身仍是硬约束。

B.2 本规范证据最薄的三处

明确列出，不用条款语气掩盖：

1. IH2-2 没有给出任何报警负荷数值。公开文献与行业实践中流传的基准值有其调查范围、装置类型与统计口径前提，本次未取得可核验的原始依据来支持任何一个通用数值。本规范因此只要求"目标被显式定义、有依据、被测量并被用于决策"。因此 IH2-2 要求结合完整响应耗时与漏处置情况验证目标合理性（来源 R26、R31）；第 5 章定义证据记录方式，不能用放宽目标替代验证。
2. IH6-4 的察觉路径缺少可核验的效果证据。长时间低事件率监视会削弱察觉能力，这一现象在研究中有讨论；但"哪一类呈现方式在多长班次内有效"没有可直接移植到具体装置的结论。本规范只要求察觉路径不是"持续注视"，不给出替代方案的效果承诺。
3. IH1 各条的呈现强度分配缺少跨场景的量化依据。"正常安静、异常显著"作为方向有广泛的工程共识，但强度档位的具体划分、对比度取值与在不同现场照度下的表现须由产品自行测定。本规范给出的是分配关系的判据，不是可直接采用的视觉参数。

B.3 本规范未做的事

不作功能安全等级的判定与认证，不规定联锁与保护功能的设计与验证，不规定工艺设计与控制算法，不作工业网络安全的符合性评估，不规定硬件与环境防护等级，不规定控制室的建筑与工效学布置、人员资质与培训认定，不给出报警速率、响应时限、对比度、刷新周期等具体数值，不指定组态软件、通信协议与画面工具，也不给配色方案与控件外形。这些是标准体系、工程学科与产品的决定；本规范只规定与操作员的监视和操作体验相关的那些决定必须被作出、必须可被检验，以及哪些取值不被允许。采用本规范不构成任何合规证明。

B.4 来源

完整的来源对照、核验状态与检索记录见 reference.md。多数相关标准的正文处于付费获取状态，本次未取得原文；reference.md 中区分了已读取的公开来源、既有资料记录与待核验线索。规范中的条款不因为某份标准存在就成立，也不因为某个厂商这样做过就成立；来源证明这类机制或这类失效存在，不直接证明某条要求适用于所有产品。

---

实施验收场景¶

以下场景把已有条款转成可复核的验收输入，不另设通用性能阈值。按产品适用能力选取，补充真实设备、用户、输入序列和证据；不适用记录原因，未执行不得记为通过。

每个场景分别核对配置的有效值、执行记录与用户可理解的结果。保留版本、目标、事件时点、失败范围和恢复结果；外部结果未知不填作成功或失败。