Industrial HMI Design Guidelines

For designers and engineers: when the interface stands behind a production plant that is actually running, let a trained operator on continuous shift read the process state, notice anomalies, tell whether the numbers on screen still count, and, when necessary, safely put a hand on the controls.

An industrial HMI is the interface through which an operator monitors and operates a production process in a control room or in the field — SCADA supervisory screens, DCS operator stations, PLC local panels, and the mobile inspection terminals carried on the body. It differs from consumer products in four fundamental ways: the user is a trained professional, but training does not substitute for clear expression of state, objects, and consequences; the shift is continuous, one person faces the same set of screens for a stretch of a shift; consequences land on equipment and on people, the cost of one mis-operation is not absorbed by an undo button; and most of the time is spent in a monitoring state where "nothing is happening" — for the vast majority of the time, the interface's job is not to be used, but to let the person believe that nothing is in fact wrong right now, and to let them know instantly the moment something is.

The most common design mistake in this domain is writing it as an industrial-style visual specification: dark backgrounds, skeuomorphic gauges, three-dimensional piping, sweeping animations, a screen packed full of dials. These decisions are about appearance, and almost none of where this domain goes wrong is about appearance — it is twenty alarms flooding in together within thirty seconds with not one of them actionable, it is a number on screen that has not updated in ten minutes but looks exactly like it does during normal refresh, it is an operator who believes a loop is in automatic when it dropped back to manual two hours ago, it is a point forced to "normal" during maintenance that nobody remembers to release. Correct appearance with any one of the above still true is a non-conforming HMI. These guidelines therefore center on behavioral requirements and give ways to land them in screens, state, and verification; concrete visual parameters are calibrated to the operating environment.

These guidelines consist of six principles and 36 rules: principles state the design direction, rules specify the applicable situation, behavior requirements, and verification method. Each rule belongs to one and only one principle, and the rule number is the principle number (IH3-2 is the second rule under the third principle). The six principles are split by the object they regulate: the presentation of process state on the interface, the class of signal that is an alarm itself, the relationship between a displayed value and the data source behind it, the control mode a device is currently in, the control actions an operator issues, and the shift process that spans time, people, and workstations.

Scope statementThese guidelines constrain the nature of the experience commitments an industrial HMI makes to operators in monitoring and operation, and the mechanisms that honor them; they do not presuppose a single technical architecture, and do not specify configuration software, communication protocols, or screen-building tools. These guidelines do not replace any mandatory safety standard; where a clause of these guidelines conflicts with an applicable mandatory standard, industry code, or site operating procedure, the applicable mandatory standard and procedure govern, and these guidelines yield. Adopting these guidelines cannot substitute for the following dedicated assessments and compliance determinations: determination and certification of functional-safety level (the leveling, verification, and independent assessment of Safety Integrity Levels belong to the functional-safety standards system; these guidelines only write "the interface MUST NOT substitute for a safety function" as a design requirement, and assign no level of any kind), process design and control algorithms (loop tuning, advanced control, optimization strategy, and process parameters are outside the scope of these guidelines), industrial cybersecurity (segmentation, authentication, remote access, and industrial-network protection must be assessed separately against applicable cybersecurity standards), hardware and environmental protection (ingress protection rating, intrinsic safety, explosion protection, vibration resistance, and temperature range are determined by equipment specification), as well as the architectural and ergonomic layout of the control room, personnel qualification and training certification, and accident investigation and liability determination. Where any of the above conflicts with a clause of these guidelines, the applicable regulation, standard, or procedure governs.

Reading order: Chapters 1–3 define the principles and the 36 rules, Chapter 4 unifies terminology, Chapter 5 specifies delivery and acceptance methods; Appendix A provides fault-injection scenarios, Appendix B explains evidence boundaries. Configuration decisions are recorded in Industrial HMI Design Token; for external basis see reference.md.

---

1. The six principles¶

The six principles split design responsibility by the object they regulate: each principle governs obligations on one category of object, and each rule belongs to the single principle whose direct regulated object matches its obligation. Different objects mean the principles do not substitute for one another — this is both the basis for the split and the way to test it.

A single scenario can touch several principles at once — at two in the morning on the night shift, a pump's discharge-pressure transmitter loses communication: the product must simultaneously face whether that value should still be presented as a real-time value (IH3-1), whether the resulting alarm is actionable and whether it will cascade into a string of downstream alarms (IH2-1, IH2-5), whether the automatic loop that depends on that measurement point has already dropped back to manual and whether the operator knows it (IH4-2), and whether this event should be a handover item at the four o'clock shift change (IH6-3). This is not a classification error: the four rules constrain obligations on four different regulated objects — one is the presentation of data trustworthiness, one is the alarm signal itself, one is the control mode, one is the continuity of the shift process. Mutual exclusivity and exhaustiveness are a claim this split submits to testing, not a fact established by declaration: when a rule's addition, removal, or attribution is in doubt, verify it against the classification check in Appendix A. If the check fails, what gets revised is the split of principles.

The two boundaries in this split that most need ongoing testing are stated explicitly here: IH1 and IH3 — IH1 governs "how must this value be presented so it can be read, how must this deviation be presented so it can be noticed"; IH3 governs "does this value still represent reality at all." Take the same pressure figure: if the problem is that it has no unit, no range, and no visible sign of rising, it belongs to IH1; if the problem is that it is the last successful reading from five minutes ago but looks identical to a real-time value, it belongs to IH3. IH4 and IH5 — IH4 governs the control-mode state itself: what it is, how it is known, under what conditions it changes; IH5 governs the control action: who has authority to issue it, how it is verified, what trace it leaves. Switching modes touches both sides; attribution follows the direct regulated object of the obligation: the object of "the current mode MUST always be visible" and "the conditions and consequences of an automatic exit MUST be knowable" is the mode state, so it belongs to IH4; the object of "what authority is needed to initiate a mode switch, whether a second check is required, what gets left in the record" is this particular action, so it belongs to IH5. If attribution disputes recur in practice at these two boundaries, the principles should be adjusted rather than adding an intermediate layer.

Principles are for understanding the rules and adjudicating attribution; they are not themselves a separate judgment item. When a principle conflicts with the reading of a specific clause, the applicable clause governs, and the ambiguity needing clarification is recorded.

A rule's attribution is singular; this does not mean a mechanism cannot be reused. A single "data-quality state" both decides how a value is presented (IH3-2), whether an alarm based on that measurement point should be suppressed (IH2-4), and whether the automatic loop depending on it should exit (IH4-6); a single "list of points currently forced and bypassed" is both part of trustworthiness (IH3-4), an object of operational traceability (IH5-5), and content that must be handed over at shift change (IH6-3). One mechanism serving several purposes is the norm; which rule it is written under depends on the direct regulated object of the obligation.

2. How to read the rules¶

2.1 The structure of each rule¶

The force of each part in one sentence: the rule text specifies the requirement; "Applies to" and "Boundary conditions" together bound the requirement's scope of application; Design application, Verification examples, Counterexamples, and Basis and references add no further obligation.

A rule writes the nature of the behavior, not the implementation: after a communication loss, the screen MUST be seen to have stopped refreshing — that is product behavior; whether this is driven by a heartbeat, by timestamp comparison, or by a quality code driving an overlay mask is an engineering solution — the two must line up, but they are not the same deliverable.

2.2 Normative terms¶

The rule text uses three levels of normative terms:

• MUST: not meeting it means non-conformance with these guidelines. Its absence would cause some commitment to the operator to fail under foreseeable conditions — this is the sole basis for marking something MUST.
• MUST NOT: the reverse statement at the same strength as MUST, identifying behavior that must not occur; the main text's two ways of writing this term, one meaning "must not" and the other meaning "forbidden," are equivalent.
• SHOULD: followed by default; when there is genuine reason to deviate, record the reason and the alternative, and accept the same verification. Deviation needs no approval, but it needs a record. "SHOULD NOT" is the reverse statement of SHOULD.

Conformance judgment takes the independent obligation clause in the main text as its unit: a declarative sentence with no normative term carries the strength of the rule heading it sits under; a clause with an explicit normative term is judged at its own strength — a MUST NOT / forbidden clause inside a [SHOULD] rule remains a hard constraint (IH1-4, IH2-6, IH3-5, IH3-6, IH4-6, IH6-2, IH6-4, IH6-5 contain such clauses), and the strength annotation on a rule heading or in the quick-reference table does not substitute for a clause's own binding force. "cannot" in the main text is used only for statements of capability or fact, and expresses no obligation.

Strength denotes binding force, not importance. No strength annotation in these guidelines changes the force of an applicable mandatory safety standard: where the mandatory standard requires more, the mandatory standard governs, and these guidelines are not grounds for relaxation.

2.3 The two sides of a counterexample¶

Counterexamples come in two sides: "under-delivery" is missing the requirement, "over-delivery" is piling the interface into a different kind of failure in the name of satisfying it. Industrial HMIs get built badly in dense ways at both ends: at one end, every anomaly gets configured as an alarm, every number gets painted red, every jog gets an extra confirmation layer; at the other end, in the name of a "high-performance display," the whole interface is rendered in a wash of gray with almost no readable information in the normal state, so the operator opens a homegrown spreadsheet on the side to watch the numbers instead — driving people to a shadow tool is just as much a failure to get it right. Restraint does not mean hiding information, and caution does not mean making every operation slower.

2.4 Rule quick reference: 36 rules¶

The table below is a one-sentence memory version of every rule; click a rule's name to jump to the full text in Chapter 3. The quick reference does not substitute for each rule's applicability conditions and full requirement; a few [SHOULD] rules contain forbidding-level clauses (IH1-4, IH2-6, IH3-5, IH3-6, IH4-6, IH6-2, IH6-4, IH6-5), and the main text governs the judgment (see 2.2).

IH1 Normal is quiet, abnormal stands out

IH2 An alarm is a managed resource

IH3 Display is no more certain than the data

IH4 Control mode is always present

IH5 Operation is authorized, verified, and traceable

IH6 The shift is continuous

3. Rules in detail¶

This chapter unfolds all 36 rules under the six principles. Each rule's structure and the binding force of each part are given in 2.1; the design application, verification examples, and counterexamples within it are only explanatory material that helps implementation — they specify no single component, and require no separate deliverable document.

3.1 IH1 Normal is quiet, abnormal stands out¶

This principle governs the presentation of process state on the interface. An industrial HMI's attention budget is scarce: for most of a shift, the operator faces a screen with no anomaly, and every extra bit of attention the interface claims is a bit less available when an anomaly appears. The core of this principle is therefore not "make the important thing stand out," but allocating visual intensity by degree of deviation — the normal state yields, the abnormal state draws on it. At the same time, information that is read must be interpretable: a number only constitutes process information once it carries a unit, a range, and its current position relative to the normal range.

IH1-1Visual intensity is allocated by deviationMUST¶

In one sentence: When everything is normal, the interface should be quiet.

Applies tomonitoring screens that continuously display process state.

RuleAttention resources on a screen — contrast, saturation, blinking, animation, and sound — MUST be allocated by "degree of deviation from normal operation"; values and states within the normal range MUST NOT use a presentation reserved for abnormal states. The product MUST explicitly define which presentation tiers correspond respectively to normal, needs attention, and needs action, and MUST ensure the same tier means the same thing on every screen. When any tier's presentation is used for a non-state purpose (brand color, section background, decoration), it MUST be visually distinguishable from the state tiers.

Boundary conditionsThis rule does not require the interface to be gray, nor does it forbid the use of color — what it requires is the allocation relationship of intensity, not an absolute palette. Both dark and light backgrounds can satisfy this rule; dialing the whole interface down to where values cannot be read does not satisfy this rule (see IH1-3). This rule also does not govern whether an alarm itself should be generated — that is IH2-1.

Design applicationFirst define a low-intensity presentation for "normal," then leave the remaining intensity for deviation; write a criterion for each tier (within the operating range / beyond the operating range but not yet alarmed / alarmed), and drive the criterion from data rather than having a screen author hand-color each one individually.

Verification examples

• User side: take a screenshot while the plant is entirely in normal operation, and check that the screen uses no presentation reserved for abnormal states and that key values are readable; then inject one deviation into the same screen and check whether it can be discovered under the product's defined noticeability conditions. (When everything is normal, there is no process deviation, and the highest-intensity element may be navigation, a primary value, or a selection indicator — this does not invalidate the judgment.)
• Implementation side: check whether the state-tier definitions are managed centrally and referenced by every screen, and whether any screen has a custom, locally defined alarm color.

CounterexamplesUnder-delivery — piping, equipment, and background use large areas of highly saturated color during normal operation, so there is no higher tier available when an anomaly appears; over-delivery — every element is pushed to extremely low contrast, so the operator must lean in close to the screen to read a single number, or falls back to a spreadsheet they maintain themselves.

IH1-2Color is not the only codeMUST¶

In one sentence: It should still read as the right state when printed in grayscale.

Applies tointerfaces that use color to represent equipment state, data quality, alarm priority, or mode.

RuleWhen color is used to represent state, color MUST NOT be the only coding method; every state distinction carried by color MUST also be independently expressed by at least one of shape, pattern, position, text label, or a value, and that non-color code MUST be obtainable without zooming, hovering, or clicking. Color and non-color codes MUST come from the same state definition; presentations where the two disagree MUST NOT occur. This rule applies equally to large screens, printouts, and mobile terminals; state distinctions MUST still hold on monochrome or low-color-gamut display devices.

In-field discriminability MUST have a stated condition of use: record viewing distance, angle, illuminance, glare, display scaling, and the font size and contrast used, per terminal; a desktop screenshot alone MUST NOT be the only thing checked. Critical states and operation feedback MUST have a perceivable path such as text or a symbol; on terminals that support a keyboard or assistive technology, focus, control names, and state notifications MUST be usable, and a routine refresh MUST NOT steal input focus. An audio cue MUST NOT be the sole clue for a critical anomaly; its audibility SHOULD be verified under actual site noise and actual protective equipment.

Boundary conditionsThis rule does not forbid the use of color, nor does it require a caption for every state; a shape difference or a position difference alone is enough to satisfy "independent expression." This rule does not specify concrete color values or contrast numbers; those are determined by the product against the applicable discriminability requirements and site illuminance, with the basis recorded.

Design applicationMake "state" an object with both a graphical and a textual rendering, both driven by the same field; during design review, walk through the key judgments with the entire screen set rendered in grayscale.

Verification examples

• User side: present key screens in grayscale and ask the operator to judge whether each piece of equipment is running, stopped, faulted, or unavailable; a judgment that fails counts as non-conforming.
• Implementation side: check whether any state-rendering branch changes only the color and no other attribute.

CounterexamplesUnder-delivery — a pump's running and stopped states are distinguished only by green versus gray, which becomes indistinguishable after color-vision difference or screen aging; over-delivery — every graphic element is hung with a caption of state text, filling the screen with text until the layout relationships can no longer be read.

Basis and referencesR09 explains that color must be used discriminably (the same color MUST NOT represent both a critical alarm and equipment stopped); R10's vendor style guide states clearly that state presentation cannot rely on color alone and must additionally use fill, shape, or short text. Both are publicly available design material, not standards requirements; concrete color values and contrast are outside the scope of these guidelines (see reference.md R09, R10).

IH1-3Values carry a unit, range, and limitsMUST¶

In one sentence: A number with no unit and no range is not process information.

Applies tointerfaces that display process variable values.

RuleWhen displaying a process variable, the engineering unit, the range or normal operating range, and the value's position relative to the configured limits MUST all be obtainable together; a bare value alone MUST NOT be presented. The unit and range may be displayed nearby, or carried by a stable screen convention, but the operator MUST NOT be required to rely on memory or consult documentation to interpret it. The number of significant digits MUST be commensurate with the measurement capability; digits beyond the measurement's resolving capability MUST NOT be used to imply precision. The unit and range for the same variable MUST be consistent across different screens, and any conversion MUST be explicitly stated. When accepting a numeric input (a setpoint, a limit, a parameter), the input control MUST make the value's engineering unit and allowed range obtainable at the same time, and MUST faithfully present the value the system actually accepted after submission — when rounding, quantization, clamping, or rate limiting makes the accepted value differ from the entered value, that difference MUST be made explicit; an echo of the entered value MUST NOT impersonate the value actually in effect.

Boundary conditionsThis rule does not require a range bar drawn next to every number; "position relative to the limits" may be carried by the value's own state presentation (the tiers in IH1-1). This rule does not specify a concrete number of decimal places; that is determined by the product against the measurement chain's actual capability, with the basis recorded.

Design applicationProvide the unit, range, and limits as part of the measurement point's definition, delivered together with the value, rather than as static text on the screen; when a limit changes, the value's presentation changes accordingly, with no need to redraw the screen.

Verification examples

• User side: ask the operator, without consulting reference material, to state a value's unit, normal range, and how far it is from alarming.
• Implementation side: sample screens and count how many values lack a unit or a range source; check that limits come from configuration rather than being hard-coded into the screen.

CounterexamplesUnder-delivery — a row of numbers on screen reads "382 / 1.7 / 96," and only a senior operator knows what each one is; over-delivery — every value is given a range scale, an explanatory caption, and a mini trend, pushing the information density of a single screen so high it cannot be scanned quickly.

IH1-4Trend is obtainableSHOULD¶

In one sentence: A single point does not show where the process is heading.

Applies tointerfaces that display a process variable that changes continuously over time.

RuleFor key variables used to judge where the process is heading, the product SHOULD provide a way to obtain the trend — a trend line, a direction-of-change indicator, a rate of change, or a comparison with the prior period all qualify; the trend's time span SHOULD be adjustable, with the span and the sampling method explicitly labeled. On a trend chart, missing data, bad values, or data during a communication loss MUST NOT be interpolated into a normal-looking curve (see IH3-2). Which variables count as "key" is determined by the product against the process and the operating task, with the basis recorded — it is not decided by how much screen space is available.

When a trend curve is displayed, the variable, unit, time window, and whether it is following in real time or viewing history MUST be labeled, and the sampling or aggregation method MUST be knowable. Auto-scaling, dual y-axes, smoothing, or downsampling MUST NOT obscure limit excursions, peaks, and the direction of change; a change in the axis MUST be visible, and extreme values MUST be retained where necessary. Looking back at history MUST NOT put historical values into a real-time control panel; after exiting the history view, the operating conditions MUST be re-checked against current data.

Boundary conditionsThis rule does not require a trend curve permanently resident for every measurement point; calling it up on demand, expanding it on hover, or a dedicated trend screen can all satisfy it. This rule does not specify a default time span for the trend.

Design applicationTreat "current value + direction" as a single presentation object; for variables where judging acceleration or deceleration matters, give a rate of change rather than only a direction arrow.

Verification examples

• User side: given a stable value and a value that is slowly rising but has not yet exceeded a limit, ask the operator to distinguish the two.
• Implementation side: create a gap in the data source and check whether the trend curve shows a break or marks the gap as missing, rather than connecting straight through it.

CounterexamplesUnder-delivery — only an alarm lets anyone discover that a temperature has been climbing continuously for four hours; over-delivery — every screen is blanketed with curves, and key variables are visually indistinguishable from irrelevant ones.

IH1-5Screen hierarchy corresponds to the monitoring taskMUST¶

In one sentence: The first glance must be able to answer "is everything normal right now."

Applies tomonitoring systems composed of multiple screens.

RuleScreen organization MUST correspond to the granularity of the monitoring task: an overview tier MUST exist that can answer "is everything currently normal, and in which area is there an anomaly," and MUST allow navigation from that tier to the corresponding area and equipment detail; operators MUST NOT be required to confirm the overall state is normal by paging through screens one by one. Every tier MUST state which question it is responsible for answering, and the same question MUST NOT be scattered across multiple screens that do not reference one another. The depth of the hierarchy and the basis for dividing it are determined by the product, with the rationale recorded — not dictated by the default structure of a configuration tool.

Boundary conditionsThis rule does not specify a concrete number of tiers or their naming, nor does it require the overview to be a single separate screen — a persistently resident area-status bar can equally serve the overview function. Requirements for cross-screen navigation and returning are in IH6-1; the division of labor between a shared large screen and an individual workstation is in IH6-2.

Design applicationFirst write down the question each tier must answer, then decide what to draw; put "whether there is deviation" and "where the deviation is" on the overview tier, and leave concrete values to the next tier down.

Verification examples

• User side: inject an area-level anomaly at the overview tier, and record the number of steps the operator needs to locate the specific piece of equipment and whether they need to search by paging through screens.
• Implementation side: check whether every screen has a stated responsibility, and whether there are screens with duplicated responsibility and inconsistent content.

CounterexamplesUnder-delivery — there is only one process flow diagram drawn following the piping layout, and judging whether things are normal overall requires opening a dozen-plus diagrams one by one; over-delivery — five tiers of screens are built for "hierarchical completeness," and the operator must click four times to reach the execute button during an emergency response.

Basis and referencesR14 finds that placing related inflow and outflow on separate display pages hindered the operator's judgment, and contrasts this case with another accident's control system that "displayed only a segment of the plant locally, with no complete overview." R15 records that the display window for a critical storage tank was pushed behind other windows, requiring a deliberate action to bring it forward before it could be seen. Both are accident-investigation findings, not display-design rules (see reference.md R14, R15).

IH1-6Decoration carries no meaning and does not compete for attentionMUST¶

In one sentence: Three-dimensional piping and skeuomorphic gauges are not a path to reading a value.

Applies tointerfaces that use three-dimensional forms, skeuomorphic controls, gradients, shadows, textures, or background imagery.

RuleDecorative presentation MUST NOT be the sole path to reading process information, and MUST NOT use a visual intensity equal to or stronger than the state tiers (IH1-1). Skeuomorphic gauges, three-dimensional piping, gloss, and shadow are not treated as carriers of process information in these guidelines: they may exist, but with them removed the screen MUST still be able to complete every monitoring and operating task. Animation and motion effects are used only to represent an actual process change or system state that is actually occurring; a continuous motion effect MUST NOT be used to represent the un-deviated state of "operating normally."

Boundary conditionsThis rule does not forbid a process flow schematic, nor does it require the interface to be flat two-dimensional; a schematic carries spatial and connection relationships, which is information, not decoration. This rule makes no ruling on color-scheme style.

Design applicationRun a "decoration-stripping test" — turn off all shadow, gradient, texture, and three-dimensional effects, and check whether every state can still be read; where it cannot, the information was hanging on the decoration to begin with.

Verification examples

• User side: have the operator complete a set of typical monitoring tasks on the screen with decoration turned off, and compare errors and time against the decorated version.
• Implementation side: check whether any state is expressed only by gloss, shadow, or a three-dimensional angle.

CounterexamplesUnder-delivery — a valve's open/closed state is expressed only by the angle of a three-dimensional model, indistinguishable from a distance; over-delivery — process connection relationships are stripped away too, in the name of "high performance," turning the screen into a numeric table, and the operator loses the basis for judging material flow.

3.2 IH2 An alarm is a managed resource¶

This principle governs the class of signal that is an alarm itself. An alarm's function is to pull the operator's attention over from somewhere else, so its total volume MUST be managed as a budget — the number of alarms is a design metric, not an operational outcome. This principle constrains an alarm's conditions for generation, the basis for prioritization, the means of suppression and clearing, and presentation during a flood period. The boundary between this principle and IH1 is: IH1 governs how the interface presents deviation, IH2 governs which deviations deserve an alarm.

IH2-1Every alarm has something an operator can doMUST¶

In one sentence: A signal with no operator response action is not configured as an alarm.

Applies tosystems that generate alarms.

RuleFor every signal configured as an alarm, there MUST exist a response action executable by the operator under on-duty conditions, and that action MUST still be valid within the time window in which the alarm occurs; when no assessment, control, mitigation, or escalation response that is still useful and concretely executable exists, that signal MUST NOT be configured as an alarm — it may be an event, a log entry, or a status display, but it does not occupy an alarm channel. A consequence having already occurred, or the window for one response having passed, does not automatically cancel the alarm qualification supported by other responses that remain valid: an alarm remains permitted under this rule if a leak has already begun but isolation is still effective, or an over-temperature has already caused loss but evacuation is still necessary. The record of an alarm's qualification MUST state item by item the response action, the effect that action is intended to achieve, the latest time or condition under which it remains useful, and the role responsible for that action; qualification MUST NOT be judged by a blanket "consequence has occurred" boolean; the record MUST be formed at configuration time and be reviewable during alarm review. An event that need only be logged does not gain alarm qualification by being configured with an eye-catching style or a high-priority color. Adding, suppressing, or modifying an alarm MUST go through rationalization and management-of-change; existing protection is retained during suppression, and the suppression state is queryable.

Boundary conditionsThis rule does not require the response action to be completed by the operator in person — "who to notify, where to escalate" is also a response action, but it MUST be concrete enough to execute. This rule does not forbid logging events that need no response; it only forbids putting them into the alarm channel. This rule also does not require a response action to be retrofitted onto a completed, closed event just to preserve its alarm status: "a completion event only worth logging" and "an initial consequence has occurred but immediate mitigation is still needed" are two different categories — the former MUST NOT be hard-coded with a response just to pad the count, and the latter MUST NOT be automatically downgraded to a log entry merely because it has already occurred.

Design applicationAdd a column "what the operator does" to every alarm's configuration item; cancel the alarm status of anything that cannot be written down. Periodically review alarms that have never been responded to — they are typically violations of this rule.

Verification examples

• User side: randomly sample several entries from a period of alarm records and ask the on-duty operator to state each one's response action; an inability to state one is a violation of this rule.
• Implementation side: count how many alarm entries in the configuration have no recorded response action.

CounterexamplesUnder-delivery — equipment power-on, valve in position, and batch start are all configured as alarms, with hundreds unaddressed in a single shift; over-delivery — to shrink the count, genuinely response-worthy low-priority alarms are downgraded to events as well, and the operator loses the chance for early intervention.

Basis and referencesThe alarm definition cited in R04 takes "requires a response" as a defining element, R05 shows that EEMUA 191 treats alert / event / prompt and "not an alarm" as separate topics alongside alarm, and R13 states that process-state indications should not be designated as alarms. R04 is a vendor's interpretation of a standard, and only the public table of contents of R05 was obtained (see reference.md R04, R05, R13).

IH2-2Alarm load is a design metricMUST¶

In one sentence: The number of alarms is fixed at design time, not produced by operation.

Applies tosystems that generate alarms.

RuleThe product MUST explicitly define alarm-load targets at the design stage — including the steady-state alarm rate, the acceptable peak, and the criteria for determining a "flood" — and make them measurable and continuously observable; when actual load exceeds the target, this MUST trigger a disposition process (reviewing configuration, eliminating the root cause, adjusting limits), and the observed actual rate MUST NOT be taken directly as the acceptable value. The target values, their basis, and the observed results MUST be queryable. When alarms from multiple sources are stacked on the same operating position, load is calculated summed over the position, not calculated separately per subsystem.

Target reasonableness MUST be verified against the operating task: under normal operation, startup/shutdown, condition changeovers, and typical anomalies, separately measure the time spent on detection, understanding, decision, operation, and waiting for effect, and any missed dispositions; the available response window comes from process consequence analysis, and cannot be reverse-derived from the current average alarm rate. Continuously observe high-frequency repeating alarms, long-standing active alarms, the number of suppressions, and items unresponded past their window, to avoid meeting the total-count target alone. When using a deadband, trigger delay, or return delay to manage chatter, its unit, the object it acts on, and its effect on alarm delay MUST be defined, and it MUST be verified that a genuinely fast anomaly still has sufficient response time; hiding repeated events only at the display layer to fake a load reduction MUST NOT be used.

Boundary conditionsThese guidelines give no concrete alarm-rate figure — benchmark values in public literature carry the scope of the survey and the plant-type premise behind them, and transplanting them directly to a different process and a different operating position does not hold automatically. What this rule requires is that the target be explicitly defined, have a basis, be measured, and be used in decisions; the number is determined by the product against applicable industry practice and its own measurement, with the source recorded.

Design applicationFold the alarm rate and flood count into the routine operating report, reviewed alongside process metrics; make "the ten most frequent alarms" a fixed entry point for improvement.

Verification examples

• User side: pull up the alarm-load statistics for a recent period and check whether there is a disposition record for periods that exceeded the target.
• Implementation side: check whether the system can compute the alarm rate and flood events by position, and whether the counting convention is recorded.

CounterexamplesUnder-delivery — the alarm rate is never tallied, and operators default to assuming half the alarms can be ignored; over-delivery — alarms are shut off in bulk to make the statistics hit target, without fixing the root cause or leaving a record (this also violates IH2-4).

Basis and referencesR13 records the number of alarms two operators had to handle in the 11 minutes before an explosion in one accident, and R11 contains a table of alarm performance metrics labeled as a paraphrase of a standard. These guidelines adopt none of these numbers: R11's table comes from a vendor white paper's paraphrase of a standard, and R13's figure is self-labeled as a secondhand citation from a guideline; the standard's original text was not obtained in either case (see reference.md R03, R11, R13 and Appendix B.2 item 1).

IH2-3Priority is based on consequence and remaining response timeMUST¶

In one sentence: Priority is not decided by how expensive the equipment is or who raised it.

Applies tosystems that classify alarms by priority or level.

RuleAlarm priority MUST be jointly determined by severity of consequence and the response time left to the operator, using a unified basis for judgment; priority MUST NOT be decided by equipment price, the discipline it belongs to, the submitting department, or a vendor default. The presentation and response expectation for each priority MUST differ clearly, and the count of high-priority alarms MUST be controlled — when the proportion of high-priority alarms is such that "priority" loses its meaning, prioritization is considered not implemented. The basis for priority judgment and the rationale for each alarm's assigned level MUST be queryable, and reviewed whenever process or equipment conditions change.

Boundary conditionsThis rule does not specify the number of priority tiers, nor does it specify the proportion for each tier; the proportion is determined by the product against its own process, with the basis recorded. This rule does not address the prioritization of general reminders outside of alarms.

Design applicationTurn leveling into a two-dimensional judgment table (consequence × available response time), and have every discipline level alarms against the same table; set up a separate review for alarms leveled at the highest tier.

Verification examples

• User side: sample several alarms at different priorities and have two people who did not participate in configuration independently level them against the judgment table, and compare consistency.
• Implementation side: tally the distribution of alarm entry counts and actual occurrence counts by priority.

CounterexamplesUnder-delivery — every alarm is "high," or each discipline levels by its own habit; over-delivery — the judgment table is split into a dozen-plus tiers, and the leveling process becomes so complex that no one is willing to review it, and leveling in practice is still just picked casually by experience.

IH2-4Alarm states are distinct, and suppression is visible and recoverableMUST¶

In one sentence: An alarm not currently shown can still be counted, and returns by its own condition.

Applies tosystems that generate or display alarms; acknowledgment, silencing, latching, suppression, and disabling requirements take effect according to actual supported capability.

RuleThe reason an alarm is not currently presented MUST be distinguishable among operator shelving, automatic suppression under a defined operating condition, maintenance disabling, and other stated mechanisms; a single umbrella term that masks their differing recovery semantics MUST NOT be used. Every item MUST be countable, and MUST carry the reason, the responsible party, the start time, the recovery condition, and the review requirement, visible on a list that can be pulled up at any time. Recovery holds separately for each of the three mechanisms: operator shelving SHOULD have an upper limit and expiration handling, returning automatically on expiry with notification given; suppression by operating condition recovers automatically per its validated condition-clearing criteria; maintenance disabling is cleared per a specified return-to-service verification, and a review deadline passing MUST NOT be automatically treated as equivalent to having met the conditions for return to service. A permanent hidden entry point with no record, no responsible party, and no recovery path MUST NOT be provided. A long-suppressed item MUST enter review, but duration alone is not proof of a configuration error — a shutdown condition lasting a long time does not make suppression-by-condition a violation.

An alarm's activation state, operator acknowledgment state, audible state, and latch state MUST be expressed separately: acknowledgment does not prove the anomaly has cleared, silencing does not prove it has been acknowledged or handled, and a latch reset is not the same as the equipment restarting. An acknowledgment request MUST be bound to the correct alarm and its event state; a newly occurring unacknowledged state MUST NOT be silently overwritten by a stale acknowledgment. After a system restart, the above states MUST be rebuilt or explicitly marked unknown, and MUST NOT default to acknowledged. Acknowledgment MAY silence audibly at the same time per system convention, but the two actual outcomes MUST be recorded separately; silencing MUST NOT be used to infer acknowledgment in reverse. A bulk acknowledgment MUST be bound to the set of events that was explicit at the time of the action, and MUST NOT sweep in alarms that arrive newly during execution. Where latching capability does not exist, mark it not applicable — do not fake an "already reset."

Boundary conditionsThis rule does not forbid suppression — suppression is a legitimate means of controlling alarm load; what it requires is the visibility and recoverability of suppression. Permanently canceling an alarm is a configuration change and goes through the change process, not the suppression mechanism. This rule does not require every category of disabling to be recovered manually, nor does it require every category to recover automatically — what it requires is that each mechanism state its own means of recovery. This rule does not specify which protocol model is used to express these states.

Design applicationMake "currently suppressed alarms" a permanently reachable list, with a count given at the overview tier; when an item returns on expiry, notify the on-duty staff explicitly rather than restoring it quietly.

Verification examples

• User side: shelve an alarm and then hand over the shift; check whether the incoming operator can discover it and know when it returns; also ask the operator to answer, for any given anomaly, the three questions "is it still present, who has acknowledged it, and when and by whom will it be recovered."
• Implementation side: check for any bypass path around the list (an engineering station directly editing configuration, a local screen with a custom filter); construct the eight situations — "active unacknowledged → acknowledged but still active → returned to normal but still unacknowledged → silenced, then a new alarm arrives → an acknowledgment request pointing at an already-closed old event → maintenance not finished but the review deadline has arrived → automatic-suppression condition clears → state rebuilt after restart" — and check that none of these states get collapsed into a single "handled."

CounterexamplesUnder-delivery — a night shift "clicks off" an annoying alarm, and no one ever learns it was turned off afterward; over-delivery — every suppression requires filling out a long form and waiting for approval, so the operator cannot use suppression in time during a flood and pulls the speaker instead.

Basis and referencesR04 explains that shelving, design-based suppression, and disabling are three states with different management meanings, and R12 requires that whether a value alarms be decided by plant mode. R04 is a secondhand verification, and R12 is a nuclear regulatory review guide whose intended audience differs from the process industries (see reference.md R04, R12; state interlocking and event binding are further supported by the public original text of R27, R28).

IH2-5A flood period has dedicated presentation and first-out discriminationMUST¶

In one sentence: When the flood arrives, a scrolling list does not help.

Applies tosystems that may experience alarm flooding.

RuleThe system MUST provide a presentation for alarm flooding distinct from the steady state, supporting at least: grouping or collapsing by relationship, so the operator sees a number of groups rather than a scrolling stream of individual entries; first-out discrimination or an explicit indeterminate result: where the source has the discriminating capability, indicate the one or the class that occurred first, and where evidence is insufficient, mark it "order not determinable"; and retaining event-sequence evidence and its limitations (see IH3-5), to support after-the-fact analysis. During a flood, reducing what is displayed by discarding, silently truncating, or keeping only the most recent several entries MUST NOT be used, unless the discarded portion is still fully retained and retrievable and this fact is stated explicitly. A scrolling list is not used as the sole presentation during a flood.

List interaction MUST preserve the object of an action: refreshing and reordering MUST NOT let the alarm under the finger at press-down become a different one at release; filtering, collapsing, and pausing scroll MUST show their scope, the count of hidden or newly added items, and MUST retain an entry point for returning to the full view. Local filtering MUST NOT eliminate position-level critical alarm indication. Where the interface shows no entries, it MUST be able to distinguish "currently no alarms," "hidden by a filter," "still syncing," and "data invalid."

Boundary conditionsThis rule does not require the system to automatically produce a root-cause conclusion — grouping and first-out are information that helps a person judge, not a diagnostic result; a correlation inference the system produces MUST be labeled separately from what actually occurred. This rule does not specify the threshold for determining a "flood" — that is defined by IH2-2.

Design applicationPredefine correlation relationships (equipment dependency, process upstream/downstream, common cause) as part of alarm configuration, rather than guessing from timestamps once a flood happens; give the operator a "show only the first of each group" view.

Verification examples

• User side: inject a typical cascading trip, and record how long it takes the operator to identify the event that occurred first and whether they need to search through history afterward.
• Implementation side: check whether any alarms are silently discarded during a flood, and whether discarded items remain fully retrievable.

CounterexamplesUnder-delivery — at the instant of a trip, two hundred alarms scroll past in reverse chronological order, and the one that occurred first is pushed off the list; over-delivery — a grouping algorithm merges unrelated alarms into one, masking an independent new problem.

Basis and referencesR12 §4.1.2-6 explains that first-out handling identifies the parameter that first exceeded a limit among a group of related parameters, and notes that its usefulness is limited where response characteristics vary with time; §4.6-3 requires that the first-out display be available at the primary workstation and at the plant overview. R05 shows that first-out alarm is a separately named topic in EEMUA 191 (only the table of contents was viewed) (see reference.md R12, R05).

IH2-6An alarm provides response guidance but does not substitute for procedureSHOULD¶

In one sentence: An alarm tells you something is wrong, not everything you should do about it.

Applies tosystems that provide alarm response guidance, disposition prompts, or recommended actions.

RuleEvery alarm SHOULD have response guidance obtainable nearby — likely cause, information that needs confirming, executable actions, and the escalation path; guidance SHOULD stay consistent with the current operating procedure and state its source, applicable condition, and maintenance responsibility. Guidance MUST NOT be presented as a substitute for procedure or as a source of authority to interpret procedure; where guidance conflicts with the applicable procedure, the procedure governs, and the conflict itself SHOULD be recorded and trigger review. A recommended action generated automatically by the system or derived from statistics MUST be labeled separately from content that comes from procedure (see IH3-6).

Boundary conditionsThis rule does not require the entire procedure to be moved into the interface; guidance may be a summary plus an entry point to the procedure. This rule does not require guidance to be written for every low-priority alarm.

Design applicationBind guidance to alarm configuration and link it to the same authoritative procedure source, so that when the procedure is updated, the guidance is invalidated pending update together, rather than two texts maintained separately.

Verification examples

• User side: randomly sample alarms and check whether their guidance is obtainable within the disposition time and whether its content matches the current procedure.
• Implementation side: check the correspondence between guidance content and its linked procedure, and whether any guidance has gone long unupdated.

CounterexamplesUnder-delivery — an alarm has only one line of coded text, and a new employee must call the shift supervisor to ask; over-delivery — every alarm pops up an entire page of disposition steps that forces reading, blocking the operator's access to the controls in an emergency.

3.3 IH3 Display is no more certain than the data¶

This principle governs the relationship between every value on screen and the data source behind it. An industrial HMI's screen is a layer of retelling: a value travels through sensors, transmitters, controllers, communication links, and a screen refresh before it reaches the eye, and a problem anywhere along that chain can leave the screen still displaying a number that looks perfectly normal. This principle's requirement is a single sentence: the interface's presented degree of certainty must not exceed what it actually knows. It does not require the system to be more accurate; it only requires the system to be honest about the parts of itself that are inaccurate — uncertainty must look uncertain, staleness must look stale, and a value a person has altered must look altered. The boundary between this principle and IH1 is given in Chapter 1: IH1 governs how a value must be presented to be read, IH3 governs whether this value still represents reality at all.

IH3-1A real-time value and the last known value are distinguishableMUST¶

In one sentence: Is this the number right now, or the last one that was read.

Applies tointerfaces displaying process values from a remote data source.

RuleA value that is actively updating in real time and "the value last successfully read" MUST be distinguishable on the interface, and that distinction MUST be obtainable without hovering, clicking through, or checking a log. When presenting the last known value, the time it was obtained or how long it has been stale MUST be obtainable at the same time; the product MUST define, for each type of value, the condition under which it is judged "no longer real time," and that condition MUST be commensurate with the data source's actual update characteristics. Once a data source has stopped updating, that value MUST NOT continue to be displayed with a real-time presentation. A value whose cycle is inherently long (manually entered lab data, per-shift tallies) is not judged stale merely because of this, but its update cycle MUST be obtainable.

An unchanged value is not the same as acquisition having stopped. Change-of-value reporting, deadband reporting, and periodic sampling MUST each declare their own evidence of liveness; source time, receipt time, and the last successful verification time MUST NOT be mixed together, and refreshing the browser's clock MUST NOT turn a cached value into a new one. A communication heartbeat alone proves link liveness; it does not by itself prove the sensor is measuring normally — where the two cannot be distinguished, this evidentiary limitation MUST be stated.

Boundary conditionsThis rule does not require every value to permanently display a timestamp; a single state indicator plus an obtainable time is sufficient. This rule does not specify a duration for judging staleness — that duration is determined by the product against each data source's actual update cycle, with the basis recorded. A whole screen ceasing to refresh is covered separately in IH3-3; the quality of the value itself is covered separately in IH3-2.

Design applicationProvide "value + time obtained + whether real time" to the screen as a single data object, rather than letting each screen decide on its own whether to show time; for values whose update cycles differ greatly, set staleness criteria by data-source category rather than one threshold for the whole system.

Verification examples

• User side: cut one data source and ask the operator to point out on screen which values are no longer real time, and to state when each one's data is from.
• Implementation side: check whether staleness criteria are configured by data-source category, and whether any screen path caches the previous frame's value directly and renders it as usual.

CounterexamplesUnder-delivery — after a communication loss, a pressure value sits at 1.8 MPa, presented identically to a normal refresh, and the operator concludes on that basis that the plant is stable; over-delivery — every value gets a second-resolution timestamp line, half the characters on screen are constantly ticking, and the actual staleness indicator is drowned out among them.

IH3-2Data quality is expressed explicitlyMUST¶

In one sentence: A bad value MUST NOT render as zero, and MUST NOT render as the last good value.

Applies tosystems whose data sources can provide quality, status, or validity information, and interfaces where bad values, over-range values, disconnection, and uninitialized values can occur.

RuleA value's quality state MUST be expressed in its presentation, distinguishing at minimum usable, suspect, and unusable; an unusable value MUST NOT be rendered as a number that looks normal — including rendering as zero, rendering as the bottom of the range, rendering as the last valid value, or being filled with a default. Quality state MUST flow together with the value to every consumer where that value actually exists: the screen, trends, reports, and alarm judgment use the same quality information, and a situation where the screen shows a bad value while an alarm still computes from it MUST NOT occur; the product MUST NOT evade this rule by simply not registering some consumer. The concrete meaning and generating conditions of the suspect tier, and whether it may continue to participate in computation under each consuming use, MUST be defined separately and be queryable — suspect does not automatically mean "treat as most conservative"; a report, a trend, and alarm judgment may each apply a different, defined disposition to the same suspect value, but that MUST NOT be left to each one's own default behavior.

Quality, whether quality evidence is known, human override, time obtained, the last time it was successfully verified valid, and protection-bypass state MUST be retained separately, and MUST NOT be merged into a single judgment. When there is no quality evidence, present it as unverified; "refresh is normal" MUST NOT be used as proof that a value is usable; a protection-bypass indicator is bound to the affected protection function and object, not conditioned on whether the measurement source has changed — under a bypassed interlock, the sensor reading may still be true; what has failed is the protection relationship.

Boundary conditionsThis rule does not require the interface to display the underlying protocol's quality codes verbatim to the operator; what it requires is that these quality distinctions not be flattened away. This rule does not specify a finer breakdown beyond the floor on the number of quality tiers, nor does it require every data source to be capable of providing quality information — where it cannot, the product MUST, per IH3-1, use timeliness as an obtainable substitute criterion marked as unverified; normal timeliness does not constitute proof that quality is usable, and this limitation MUST be recorded. This rule does not require every consumer to uniformly discard suspect values; what it requires is that the disposition for each use has been defined.

Design applicationTreat quality as an intrinsic attribute of the value object rather than an add-on decoration; separately confirm, across trends, statistics, and alarms, that the handling of bad values (skip, break, flag) has been explicitly defined, rather than left to each one's default behavior.

Verification examples

• User side: inject a disconnected analog point and ask the operator to judge whether that location currently has a usable reading.
• Implementation side: check whether the handling of a bad value is consistent across the four paths of screen, trend, alarm judgment, and shift report; check for any conversion step that silently replaces a bad value with zero or the previous value.

CounterexamplesUnder-delivery — after a transmitter disconnects, the analog value returns zero per protocol, the screen shows "level 0%," a low-level alarm fires immediately, and the operator responds as for a low level; over-delivery — every suspect value is turned into a sight-blocking, eye-catching marker, and brief suspect states caused by normal fluctuation keep the screen flashing continuously until the operator learns to ignore the marker.

Basis and referencesR17 specifies that the result of a failed status MUST NOT be used and that a client MUST check the status code before use; R18 gives concrete status vocabulary under usable / suspect / unusable (including substitute value, initial value, and last usable value when there is no communication); R12 §14.3 requires an indication for invalid data and marks data that failed an accuracy check as unverified. The protocols specify the data contract; they do not specify how the interface presents it (see reference.md R17, R18, R12).

IH3-3A screen that has stopped refreshing MUST NOT look like normal operationMUST¶

In one sentence: A frozen screen is the most dangerous kind of "normal" in this domain.

Applies tomonitoring screens that depend on continuous data updates, including workstations, shared large screens, and mobile terminals.

RuleWhen the update chain between a screen and its data source is interrupted, the screen's process stops responding, or a display terminal loses contact with the system, that screen MUST indicate, in a way perceivable by the operator at normal monitoring distance and normal attention level, that it is no longer updating; this indication MUST NOT depend on the operator proactively checking a timestamp tucked in a corner. The product MUST define, for each type of display terminal, the criterion for "still updating" and the presentation for its failure, and MUST ensure that presentation can still be produced when the chain is interrupted — an interruption indicator that depends on the very chain that has been interrupted does not satisfy this rule. This rule applies equally to unattended shared displays.

Restoring communication is not the same as restoring monitoring. After a first connection, a reconnection, or a service switchover, the current value, quality, mode, operating authority, active and unacknowledged alarms, and the intervention list MUST be checked before the failure indication is cleared, and only to the extent that actual synchronization has completed. A stale event MUST NOT overwrite a newly received state; rebuilding the active-alarm list is not the same as backfilling the history for the interruption period, and gaps in history MUST be marked separately. No control command is automatically resent during recovery, and control authority is not restored on the strength of a cache alone. When the screen's own process is hung, a timer inside that same process cannot serve as the fault indicator; there MUST be a watchdog outside the process, an independent signal, or a validated alternative monitoring path.

Boundary conditionsThis rule does not require the screen to clear or go black when contact is lost; retaining the last screen with a clear failure indication overlaid is an acceptable approach (the individual values on that last screen remain governed by IH3-1). This rule does not specify that the means of perception must be visual, nor does it specify the duration for judging an interruption. A planned maintenance window does not exempt this rule — only its indication may include a stated reason.

Design applicationMake "am I still alive" a state that the display terminal itself can determine locally, driven by an independent mechanism on the terminal side, rather than waiting for the server to push a "you have disconnected" message; for unattended terminals such as large screens, design the failure indication to be visible from a distance.

Verification examples

• User side: cut a workstation's data link without the operator's knowledge, and record the process from interruption to the operator's noticing and what cue they relied on.
• Implementation side: separately inject a network interruption, a server stop, and a hung screen process, and confirm all three produce a failure indication; check whether producing that indication depends on the very chain that was interrupted.

CounterexamplesUnder-delivery — a control-room large screen stays frozen on a screen from two hours before a service restart, and on-duty staff believe all night that the plant is stable; over-delivery — a one-second network jitter pops a full-screen interruption overlay that covers the controls, and the operator is blocked by the overlay right when they genuinely need to act.

Basis and referencesR15 records that a stuck servo level gauge made the level display "flatline," and it had already stuck 14 times in the three-plus months before the accident; "last usable value when there is no communication" in R18 is this situation's existing expression at the protocol level (see reference.md R15, R18).

IH3-4Force, bypass, and simulation MUST be explicit and countableMUST¶

In one sentence: Who changed it, to what, and how many are still not restored.

Applies tosystems that provide point forcing, signal bypass, output override, interlock removal, or simulation-run capability.

RuleAny human intervention that changes the source of a displayed value, a control output, or a protection relationship MUST be explicitly indicated everywhere that value or affected object appears; the indication MUST NOT exist only on an engineering station or a single dedicated screen. The system MUST provide a list of every point currently forced, bypassed, overridden, or in simulation, retrievable at any time, containing who performed it, when, the reason, and the expected restoration condition; the list's current count SHOULD be obtainable within the operator's routine field of view. An intervention path that does not enter this list MUST NOT be provided. Entering or exiting simulation-run mode MUST be an explicit action and be notified to on-duty staff, and a screen under simulation MUST be distinguishable from a screen under actual operation.

Boundary conditionsThis rule does not forbid forcing and bypass — they are legitimate means for maintenance and commissioning; what it requires is that these states cannot go invisible. This rule does not specify a review cycle for the list, nor does it require the system to automatically clear a force; automatic clearing is itself a risk in some scenarios, and whether to set a deadline is determined by the product against its process, with the basis recorded. Suppression of a related alarm is covered separately in IH2-4; the trace and review of the action are covered separately in IH5-5.

Design applicationDeliver intervention state to the screen through the same mechanism as data quality (IH3-2), so that neither "this value was given by a person" nor "this value is bad" can be silently treated as a normal reading; put the list's count on the overview tier, so "how many forces are currently on the plant" is information obtainable at a glance.

Verification examples

• User side: set forces on several points and ask the operator to count the number and location of currently intervened points, comparing their result with the system's list.
• Implementation side: enumerate every entry point that can change a point's source (screen, engineering station, offline configuration, commissioning tool), and confirm every one writes to the same list.

CounterexamplesUnder-delivery — three interlock signals bypassed during maintenance are forgotten by everyone after restart, and are only discovered a month later in an offline configuration during an accident investigation; over-delivery — every forced point is presented with a continuously flashing red box, dozens flash simultaneously on screen during maintenance, and the operator ends up suppressing the entire indicator scheme.

Basis and referencesR18's status vocabulary already includes both simulated value and local force, showing that this kind of intervention is already treated in the existing data contract as a state requiring separate indication; R15 records that control-room permission settings allowed all personnel to change any parameter, including alarm setpoints. Neither specifies how the interface presents it (see reference.md R18, R15).

IH3-5Time and sequence are determinableSHOULD¶

In one sentence: The order of events is a precondition for judging causation.

Applies tosystems that record events, alarms, and operations, and that may be used for after-the-fact analysis.

RuleAn event's timestamp SHOULD be able to support judging "which came first": the product SHOULD make clear where a timestamp is generated (a field device, a controller, or upper-level software), and ensure that sources participating in judging the same causal chain use a comparable time basis. When time bases are not comparable, clocks are not synchronized, or the order cannot be determined, presentation order MUST NOT be used to imply the order of occurrence — the arrangement of a list does not constitute a temporal conclusion. The time zone and daylight-saving handling of a timestamp SHOULD be made clear, and records spanning shifts and spanning days SHOULD be unambiguous. Sequence information used for first-out discrimination (IH2-5) SHOULD come from a source with the corresponding discriminating capability, with that source noted.

Boundary conditionsThis rule does not require system-wide clock synchronization to any particular precision — the resolution needed depends on the process dynamics being judged, and is determined by the product with the basis recorded. This rule does not require every event to have sequence-determining capability; what it requires is that the boundary of that capability is stated, rather than assumed to exist by default.

Design applicationSave the location where a timestamp was generated as a field of the event record itself; in an after-the-fact analysis view, give records with differing time bases a distinguishable presentation, rather than interleaving them into what looks like a single certain timeline.

Verification examples

• User side: given the record of a cascading event, ask two analysts to independently judge which occurred first, and compare their conclusions and the basis for each.
• Implementation side: create a clock offset between the upper-level software and a controller, and check whether the event list still presents causal order by arrangement without qualification.

CounterexamplesUnder-delivery — an after-the-fact analysis sorts all records by the time the upper-level software received them, network queuing puts the genuinely first event in seventh place, and the investigation reaches a wrong conclusion; over-delivery — in the name of "absolutely reliable ordering," every record is required to carry a high-precision time source, and events that cannot meet that condition simply go unrecorded, losing a large amount of otherwise-usable information instead.

IH3-6Derived values and measured values are labeled separatelySHOULD¶

In one sentence: A calculated value and a measured value must not look the same.

Applies tointerfaces displaying values obtained through calculation, inference, soft-sensing, statistics, or model estimation.

RuleA value obtained through calculation or estimation SHOULD be distinguishable in presentation from a value obtained through direct measurement, and its computational basis SHOULD be obtainable — the inputs used, the method's name and basis, and its behavior when an input is missing or suspect. A derived value MUST NOT be presented under the name of a measured value. A derived value MUST state its required inputs, redundancy or substitution rules, and validity boundary, and its output quality is judged accordingly: when a required input is unusable (IH3-2) or stale (IH3-1), it MUST NOT continue to be presented as a normal value; where a validated substitute input exists and the input contract is still satisfied, it MAY continue to be presented as a normal value with the input combination used noted. Continuing to present a normal value while the input contract is not satisfied is a failure of this rule. A diagnosis, prediction, or correlation inference produced by a model or statistics SHOULD be labeled separately from a fact that has actually occurred, and stated as an inference.

Boundary conditionsThis rule does not require the formula to be displayed on screen; an obtainable computational basis can be a single explanatory entry point. This rule does not object to the use of soft-sensing and inference — they are valuable when direct measurement is unavailable; what this rule requires is that their nature not be hidden. A simple unit conversion or range scaling is not a derived value in the sense of this rule.

Design applicationTreat a value's source type (measured, calculated, manually entered, estimated) as an attribute of the value object, carried at the same layer as quality and timeliness; for an inference-based diagnostic conclusion, make "what is the basis" reachable from the same entry point as the conclusion itself.

Verification examples

• User side: ask the operator to point out, on one screen, which numbers are measured by an instrument and which are calculated, and compare their judgment with the actual configuration.
• Implementation side: invalidate the input point of a soft-sensing value and check whether the derived value correspondingly shifts to suspect or unusable, rather than continuing to compute from the last valid input.

CounterexamplesUnder-delivery — a column composition derived from three measurement points is used as if it were an online analyzer reading, and one of those three points has been forced without anyone knowing; over-delivery — every derived value is forced to expand its full calculation chain and input list next to it, turning the operating screen into a formula sheet, making key values harder to locate instead.

3.4 IH4 Control mode is always present¶

This principle governs the control mode a piece of equipment, loop, or plant is currently in, and the division of labor between automatic and manual. Mode confusion is a classic cause of accidents in this domain: a person believes they are in control while automatic is actually acting, or believes automatic is still working when it has already long since exited. Its distinguishing feature is that the person in the moment of the error does not feel they are erring — every action is correct for the mode they believe they are in. This principle is therefore not satisfied by "mode is queryable," but requires mode to be present: in view without asking, without recalling, without clicking anything open. The boundary between this principle and IH5 is given in Chapter 1: the mode state itself belongs to IH4, the action of changing mode belongs to IH5.

IH4-1The current control mode is persistently visibleMUST¶

In one sentence: You know who is in control right now without clicking anything open.

Applies tosystems where a controlled object has more than one control mode (manual/automatic, local/remote, cascade/series, maintenance/operating, etc.).

RuleA controlled object's current control mode MUST be simultaneously visible with that object's other state, without requiring the operator to take an additional action to learn it; the mode's presentation MUST be bound to that object's position on screen, rather than existing only in a single, centralized mode list. When a screen provides an operating entry point for an object, that object's current mode MUST be obtainable within the same field of view. Mode presentation is governed by IH1-2: it MUST NOT be distinguished by color alone. When mode is unknown or indeterminate, it MUST be presented as unknown; it MUST NOT be presented as the default value of any specific mode.

Control source, control method, and equipment operating state MUST be explained separately: local/remote states where the command comes from, manual/automatic/cascade states the control method, running/stopped/tripped states the equipment's state, and operating authority states who currently may issue commands. They can hold simultaneously; a synthesized, mutually exclusive "local/remote/automatic/stopped" menu MUST NOT be composed. Each dimension is defined against the controlled object's actual capability; a dimension it does not support is not forced in.

Boundary conditionsThis rule does not require every graphic element to carry a line of mode text; a stable shape or position convention is sufficient to carry it. This rule does not specify how modes are divided or named — that is decided by the control system and the process; but the semantic consistency of a mode with the same name is governed by IH4-5. An object with only a single, non-switchable control mode is recorded "not applicable."

Design applicationMake mode and state two attributes of the same display object, so the two cannot be rendered separately; for operating-panel-style interfaces, place mode presentation adjacent to the operating control, so that "I'm about to act on it" and "who currently owns it" complete within the same glance.

Verification examples

• User side: randomly point at several controlled objects on screen and ask the operator to state each one's current control mode without clicking anything.
• Implementation side: check for any screen that provides an operating entry point but does not show mode; check the rendering branch for when mode is unknown.

CounterexamplesUnder-delivery — a pump's start/stop button is right there on the screen, but whether it is local or remote requires opening a separate "control method" screen to find out; over-delivery — every object is stacked with four lines of text for mode, sub-mode, in-service state, and permission, filling the screen with state text and crowding out the actual process information instead.

Basis and referencesR12 §9.4-1 requires that the current mode be indicated by a prominent design feature, and describes mode error as an inappropriate action, or a required action not taken, "resulting from believing the system is in one mode when it is actually in another"; the R20 abstract notes that adding modes without supporting the cognitive demands that come with them produces new forms of error. Only the abstract of R20 was obtained this time (see reference.md R12, R20).

IH4-2A mode change is noticeable and traceableMUST¶

In one sentence: Even dropping back to manual by itself counts as a change.

Applies tosystems where the control mode may change.

RuleEvery change of control mode MUST be noticeable to the on-duty operator, whether that change is initiated by a person or by the system itself; a system-initiated exit from mode (exiting automatic due to a bad input, an over-limit, actuator saturation, communication loss, or an internal protection function) MUST be presented the same as a manual switch, and its reason MUST be obtainable. Every mode change MUST be recorded, with the record containing the time of change, the mode before and after, the initiator (person or system), and the reason; this record MUST be retrievable afterward alongside the operating record and the alarm record. A mode-change path that produces neither presentation nor a record MUST NOT exist.

Boundary conditionsThis rule does not require every mode change to raise an alarm — whether it is configured as an alarm is judged by IH2-1 and IH2-3; what this rule requires is noticeability and traceability, and a single state change plus one event record is sufficient. This rule does not specify how long the change presentation must persist.

Design applicationTreat "the system spontaneously exiting automatic" as a category of event requiring dedicated design, rather than letting it reuse a generic state refresh; at the design stage, enumerate every condition that could cause an exit from automatic, and confirm the presentation and reason text for each one individually.

Verification examples

• User side: make a loop that is in automatic exit automatic due to a bad input, and record whether the operator notices and whether they can state the reason for the exit.
• Implementation side: enumerate every path that can change mode (the operator, upper-level software, controller-internal logic, a local panel, a configuration download), and confirm that every path produces both a presentation and a record.

CounterexamplesUnder-delivery — a loop drops back to manual overnight due to transmitter chatter, and on screen only a small marker changes from "A" to "M," with no event and no reason, and by the time the day shift takes over the output has drifted far off; over-delivery — every normal batch-sequence mode switch is turned into an eye-catching notice requiring confirmation, and the operator is repeatedly interrupted during normal operation, gradually losing sensitivity to mode-change prompts altogether.

Basis and referencesR12 §9.4-4 through §9.4-6 require a prompt and mandatory manual confirmation for a mode change with significant consequences, separate notification before and at the time an automatic mode change occurs with time allowed to adjust, and that the condition triggering the change be readily obtainable. This document is a nuclear regulatory review guide, and its "should" is addressed to reviewers (see reference.md R12).

IH4-3The scope and exit conditions of automatic are knowableMUST¶

In one sentence: What it is doing, on what basis, and when it will let go.

Applies tosystems with automatic control, automatic sequencing, automatic optimization, or automatic disposition capability.

RuleFor every automatic function currently in service, the operator MUST be able to obtain three things: which objects it currently acts on, what target or setpoint it currently acts by, and under what conditions it will stop or exit. These three things MUST be obtainable while the automatic function is running, not written only in a design document or in configuration. Where an automatic function has a defined scope of applicability (an operating-condition range, preconditions for being placed in service, dependent measurement points), that boundary MUST be obtainable; when the operating state has approached or gone beyond that boundary, the object MUST NOT be presented as though it were in normal operation only. Where multiple automatic functions act on the same object simultaneously, their relationship and order of priority MUST be obtainable.

For automatic sequences and batch tasks, the current step, the completed steps, the transition condition to the next step, the reason for waiting, and the distinction among pause, stop, abort, and resume MUST be queryable; the interface MUST NOT fabricate progress with a timed animation. When a recipe or step parameter is changed, it MUST be stated whether it acts on the current batch, unexecuted steps, or subsequent batches, and the affected conditions MUST be re-checked per IH5-2; resuming a sequence MUST NOT default to redoing a step that has already produced a physical effect.

Boundary conditionsThis rule does not require the control algorithm or tuning parameters to be shown to the operator; "what basis it acts by" means the target, setpoint, and constraints, not the implementation. This rule does not require a separate description written for every basic loop — loops of the same type may be covered by a unified convention. State handover after an automatic exit is governed by IH4-4.

Design applicationProvide "scope of action, current target, exit conditions" as three standing pieces of information for an automatic function, delivered together with its in-service state; for high-level automatic functions spanning multiple loops (advanced control, automatic start/stop sequences), give the scope it is currently managing at the overview tier.

Verification examples

• User side: while an automatic function is running, ask the operator to state which objects it is controlling, what the target is, and under what conditions it will exit.
• Implementation side: check whether the stated exit conditions and the actual exit criteria in the control logic come from the same source, and check for any exit path that exists only in code and is never presented.

CounterexamplesUnder-delivery — an automatic optimization function changes the setpoints of a dozen-plus loops in the background, and the operator can only see the setpoints changing, with no idea who is changing them or on what basis; over-delivery — the entire control-strategy structure diagram and every parameter are moved onto the operating screen, and the operator needs to understand control-engineering content just to complete routine monitoring.

IH4-4The state needed for takeover is given before takeoverMUST¶

In one sentence: Handing back control authority is not the same as handing back control.

Applies tosystems where a scenario exists in which automatic hands control over to a person.

RuleWhen an automatic function exits or is switched to manual, the system MUST make the state needed to take over obtainable to the operator: the current output value or actuator position, the target and deviation before the automatic exit, the reason that caused the exit, and the list of objects currently in a manual state. A planned switch MUST occur without disturbance, or the disturbance MUST be stated explicitly — if the switch itself will cause the output to jump, that jump MUST be foreseeable before the switch, and MUST NOT be handed over as a silent jump. A sudden exit triggered by protection, a bad value, or a fault may not have time for advance notice: in that case, without delaying a necessary protective action, the actual output, the reason for the exit, and the current constraints MUST be presented promptly, and the possibility of such an exit and its handover method MUST be knowable in advance; "the interface stated it" MUST NOT be used to legitimize an output jump that is otherwise not permitted — the limits on the output jump itself are determined by the corresponding control and process-safety conventions, not by the interface's wording. When a handover occurs during an abnormal operating condition, the system SHOULD also give which constraints currently apply to that object (interlock state, limits, the effect of other automatic functions). Completed handover MUST NOT be indicated solely by a change in the mode marker.

Boundary conditionsThis rule does not require the system to give disposition recommendations — giving recommendations falls under IH2-6, and must not substitute for procedure. This rule does not specify the presentation form of the information needed for handover, nor does it require complete handover information for every routine manual/automatic switch; handover during an abnormal operating condition is the primary scenario this rule targets.

Design applicationDesign "exiting automatic" as a handover, not a state jump: at the moment of exit, gather the reason, current output, deviation, and constraints at the location the operator is already looking at; for automatic functions that may exit during an abnormality, design their exit presentation in advance.

Verification examples

• User side: trigger an automatic exit during an operating condition with a deviation present, and record whether all the information the operator needs to judge "what to do now" is already at hand, and whether they need to open another screen to find it.
• Implementation side: check whether a planned manual/automatic switch has any path with an output jump, and whether there is a foreseeable notice before the jump; for a sudden exit, check whether the notification mechanism would delay a necessary protective action, and whether the actual output and reason are obtainable promptly after the exit.

CounterexamplesUnder-delivery — advanced control exits entirely overnight because a measurement point became suspect, the loop falls back to manual, and the valve positions all sit at the opening they happened to be at the instant of exit; the operator does not discover the next morning that the column has been drifting the whole time; over-delivery — every exit from automatic forces a page of a handover checklist requiring item-by-item confirmation to pop up, and the operator is blocked by the checklist right when they need to adjust a valve immediately.

Basis and referencesR19 argues that prolonged monitoring of an automated process degrades skill, while a takeover, when needed, in turn demands higher skill under lower workload; R12 §9.4-3 requires stating how the new mode changes automation's operation, its effect on the plant, and the operator's responsibilities. R19 is a 1983 discursive review, not empirical research (see reference.md R19, R12).

IH4-5A mode with the same name means the same thing everywhereMUST¶

In one sentence: "Manual" on two different screens MUST be the same thing.

Applies tosystems composed of multiple subsystems, multiple vendors' equipment, or multiple generations of screens.

RuleA control mode with a given name MUST refer to the same thing across the entire range visible to the operator; when the same-named mode in different subsystems actually has different semantics, the same name MUST NOT continue to be used in presentation to the operator — it MUST be renamed, qualified, or clearly distinguished in presentation. The mode name, its meaning, and its effect on operation MUST have a single unified source, referenced by every screen; a newly integrated subsystem MUST complete a mode-semantics reconciliation, and MUST NOT simply carry over its own built-in mode naming. For the same object appearing on a local panel and on an upper-level screen, the mode presentation MUST be consistent, or the difference MUST be clearly stated.

Boundary conditionsThis rule does not require unifying the internal mode implementation of different vendors' equipment, nor does it require each subsystem to modify its control logic; what it requires is that the name and semantics presented to the operator are consistent. This rule does not specify a naming convention.

Design applicationWhen integrating a new subsystem, make "mode reconciliation" a fixed deliverable item, confirming the meaning of every mode name in the context of this plant one by one; keep the mode definitions centrally maintained in one place, with screens pulling values from it rather than each hard-coding its own text.

Verification examples

• User side: take one object each from two subsystems with different origins that are both labeled with the same mode name, and ask the operator to state who currently controls each of the two objects and what they themselves can do, comparing their answer against reality.
• Implementation side: inventory every mode name that appears across the whole system and its source of definition, and find entries where the same name has different meanings or different names have the same meaning.

CounterexamplesUnder-delivery — vendor A's "remote" means controlled by the upper-level computer, vendor B's "remote" means controlled by a local control cabinet, and the two are displayed side by side on the same screen; over-delivery — in the name of absolute precision, mode names are turned into a string of long codes prefixed with the subsystem name, and the operator cannot read out their actual meaning in an emergency.

IH4-6Automatic MUST NOT silently compensate in a way that masks an anomalySHOULD¶

In one sentence: The valve is already wide open — that fact needs to be said.

Applies tosystems with closed-loop control, automatic regulation, or automatic compensation capability.

RuleIn the process of maintaining a controlled variable, automatic control absorbs disturbances, and this process itself can mask an equipment or process condition that is worsening. The product SHOULD make this kind of automatically absorbed deviation noticeable: an actuator approaching or reaching a travel limit, a control output drifting in one direction over the long term, the manipulated quantity needed to maintain the same target continuously increasing, and an automatic function repeatedly triggering the same compensation — these situations SHOULD be identified and presented, and SHOULD NOT be reflected only as "the controlled variable has stayed steady." When an automatic function has no remaining margin to keep compensating, that object MUST NOT continue to be presented as though it were operating normally. Whether the above situations are configured as an alarm is judged per IH2-1 and IH2-3; this rule presupposes nothing about that.

Boundary conditionsThis rule does not require the system to produce a fault-diagnosis conclusion — identifying that "the manipulated quantity is continuously increasing" is a factual presentation, while judging "this is heat-exchanger fouling" is a diagnosis, and if the latter is given, it MUST be labeled as an inference per IH3-6. This rule does not specify concrete values or windows for judging "continuous" or "approaching the limit"; those are determined by the product against equipment characteristics, with the basis recorded.

Design applicationTreat actuator margin as a piece of visible information equally important as the controlled variable itself, rather than something obtainable only on a diagnostic screen; for key loops, fold "the manipulated quantity needed to maintain the current target" into routine trend observation.

Verification examples

• User side: simulate a slowly developing increase in resistance where the controlled variable stays within the normal range the whole time, and record whether the operator can notice it before the actuator reaches its limit.
• Implementation side: check whether states such as actuator saturation and one-directional output drift are captured and presented, or whether they appear for the first time only when automatic is exited.

CounterexamplesUnder-delivery — a temperature display stays steady for eight months until the control valve is fully open at 100% and can no longer compensate, and the plant goes out of control within minutes; over-delivery — every normal regulating action is turned into an "automatic is compensating" notice, with compensation information scrolling continuously on screen, drowning out the genuine exhaustion of margin when it happens.

3.5 IH5 Operation is authorized, verified, and traceable¶

This principle governs the control actions an operator issues through the interface. A single click on an industrial HMI can start a pump, open a feed line, or reset an interlock — its consequence is not absorbed by an undo button, so the design focus here is not "can it be changed back," but verifying the object and consequence clearly before an action is issued, and leaving a traceable record after the action is issued. At the same time, a line must be drawn clearly: confirmation on the interface is a checking aid for a person, not a safety measure — what it cannot stop must be stopped by an interlock or a safety function. The boundary between this principle and IH4 is given in Chapter 1.

IH5-1A critical operation uses select–verify–executeMUST¶

In one sentence: See clearly what got selected, then act.

Applies towithin systems where control commands can be issued through the interface, operations whose consequence reaches the critical level defined by the product.

RuleA critical operation MUST consist of three distinguishable steps — selecting the object, verifying the object and the intended action, and issuing execution; between selection and execution, the currently selected object and the action about to be executed MUST be clearly visible, and a critical command MUST NOT be issued with a single click. The selected state MUST be verifiable within the same field of view as the execution action, and the interface MUST NOT automatically switch the selected object while a selection is in effect. The product MUST define which operations count as critical and record the basis; the basis follows consequence, not frequency of operation.

The semantics and end condition of each category of control action MUST be explicitly defined and distinguishable on the interface: ordinary stop, emergency-stop request, fault reset, start, and continuous manipulation (jog, press-and-hold run, continuous adjustment) each change something different, each has its own way of confirming its execution result, and each has its own way of ending on loss of focus, finger release, connection loss, or terminal lock-screen. A continuous manipulation MUST stop by its defined ending method when input is interrupted; it MUST NOT remain in a continuing-action state because the interface lost contact. An emergency-stop request MUST NOT be mechanically delayed by a generic multi-step confirmation; acknowledgment is not the same as energy having been isolated, and a reset is not the same as permission to restart — the three MUST be expressed separately on the interface.

Touch and continuous manipulation MUST be verified against actual field input conditions: gloves, wet hands, vibration, mis-touching an adjacent target, dragging out of the hot zone, multi-touch, and a keyboard long-press must each be considered separately; a critical control MUST NOT be discoverable only through hover or a hidden gesture. A press-and-hold run MUST have a release or loss-of-contact ending mechanism executable on the control side, and MUST NOT rely solely on the browser sending a single release event. An ordinary confirmation, a session lock, or an overlay MUST NOT block an already-assigned, necessary emergency-stop path.

Boundary conditionsAn emergency-stop request is handled per its own action contract and is not bound by the generic three-step confirmation for ordinary critical operations. This rule does not require every operation to go through three steps — a high-frequency routine adjustment (such as a small setpoint change) forced through three steps would distort the operation; whether to include it is judged by consequence. This rule does not specify the concrete physical meaning or timing of stop, reset, and start on a given piece of equipment — that is decided by that equipment's control and safety conventions; what this rule requires is that these meanings be written down and not conflated on the interface. Nor does this rule give generic size or duration figures for touchscreen use, gloved operation, or weak mobile network conditions — the scope of task and permitted actions under these conditions are recorded by the product against the field. This rule does not require the three steps to be completed by three clicks; a single drag plus a single confirming action can also constitute verification and execution, as long as the verification step actually exists and the object is visible. This rule does not concern the content of the confirmation dialog — that is IH5-2.

Design applicationTreat selection as a persistently visible product state rather than a momentary highlight; present "what is being done to which object" on the execution control, so that verification does not require moving one's gaze back and forth between two places.

Verification examples

• User side: on a densely laid-out screen, ask the operator to perform a critical operation on a specified piece of equipment, and record whether they confirmed the object before executing and whether a mis-selection occurred.
• Implementation side: inventory every critical-operation entry point and confirm that no single-click-to-execute path exists, including shortcut keys, right-click menus, and touch gestures.

CounterexamplesUnder-delivery — densely arranged valve graphics on a process flow diagram act on a single tap, and the operator mis-touches an adjacent valve on the touchscreen; over-delivery — even changing a setpoint is turned into a three-step confirmation, and the operator, needing continuous fine adjustment, ends up confirming click after click and switches to changing the value directly on a bypass system instead.

IH5-2Confirmation carries the consequence, not just a questionMUST¶

In one sentence: "Are you sure" is not confirmation, it is one extra click.

Applies tosystems that provide a confirmation step for an operation.

RuleA confirmation step MUST carry the concrete information of this specific operation: the object, the action, the current state and the expected state after execution, and any known consequence or unmet precondition under the current operating condition; a generic confirmation containing no operation object and no consequence MUST NOT be used. When a precondition for execution is not met (an interlock not reset, upstream not ready, insufficient permission, the object in a mode that does not permit this operation), the confirmation step MUST state that condition, and the operator MUST NOT be made to confirm an operation that is bound to fail. The existence of a confirmation step MUST NOT become a reason to omit upfront validation. When the same operation is repeatedly required to be confirmed in a short period with unchanged content, that confirmation has lost its checking function, and the product SHOULD re-evaluate its configuration.

A precheck does not substitute for a re-check before execution. What is presented before confirmation is the precondition obtainable at that time and its currency; before a command is accepted and takes effect, the control system MUST re-verify permission, mode, interlocks, and action conditions against the authoritative state. If a critical object, parameter, or consequence changes after the confirmation box opens, the earlier check is invalidated, and it MUST be re-verified rather than authorized to continue on stale conditions. A condition that can only be determined at the moment of execution MUST state that limitation, and MUST NOT be disguised as having already been verified before confirmation.

Boundary conditionsThis rule does not require confirmation to be a dialog box; expanding in place, a second press, or a two-key concurrent action can all serve as confirmation. This rule does not require listing every possible consequence — what it requires is listing the key information known for this specific instance, not a generic warning text. This rule does not specify the input method for confirmation.

Design applicationGenerate confirmation content from the operation request itself, rather than writing it as static copy; run precondition validation before confirmation so the confirmation step can present the validation result, while also retaining an independent re-check before execution on the acceptance side — the two answer different questions: "can it be done now" versus "can it still be done at this instant." Write "what change invalidates a prior check" as an explicit list, rather than inferring it from how long the confirmation box has been open.

Verification examples

• User side: ask the operator, when a confirmation step appears, to state what is about to happen and to whom; an inability to state it is a failure to implement this rule.
• Implementation side: sample confirmation copy and tally the proportion that contains no object and no action; check the order between precondition validation and confirmation, and whether an independent pre-execution re-check exists on the acceptance side. Construct the three situations "permission revoked after confirmation," "taken over locally after confirmation," and "interlock state changes after confirmation," and check whether the command is blocked rather than executed on the old conditions.

CounterexamplesUnder-delivery — every operation shares the single line "Are you sure you want to perform this operation?" and the operator develops a reflexive click; over-delivery — every confirmation lists a dozen-plus possible consequences and a disclaimer, and the operator skips straight to the confirm button, with the increased reading load buying no improvement in checking quality.

IH5-3An ordinary confirmation is not evidence of implementing a safety functionMUST¶

In one sentence: What a pop-up cannot stop must be stopped by something else.

Applies toall industrial HMIs.

RuleAn ordinary HMI confirmation, prompt, warning, or on-screen display of permission is not, by itself, evidence of implementing a safety function; the product MUST NOT reduce, delay, or cancel an applicable interlock or protective measure on the strength of "the interface prompted" or "the operator confirmed" alone. Wherever risk-reduction responsibility is to be assigned to an alarm, an operator response, access control, or another HMI-related mechanism, the applicable safety lifecycle MUST make that assignment of responsibility, independence, performance requirement, human-factors requirement, and verification requirement explicit; these guidelines neither grant nor certify that protective credit, nor do they deny the possibility of such an assignment. When an operation the interface provides may interact with an interlock or protection (reset, bypass, suppression, force, permit override execution), the interface MUST faithfully present the nature of that interaction and the current protection state, and a bypass or removal MUST NOT be presented as an ordinary operation; the interface MUST faithfully distinguish ordinary control, protection state, bypass, reset, and restart, and present its true capability boundary. When an interface mechanism that has not been assigned responsibility by the safety lifecycle is bypassed or fails, the result MUST fall to the mechanism on the safety side, not to the operator's judgment.

Boundary conditionsThis rule does not forbid configuring confirmations and prompts on the interface — they have value in reducing mis-operation; what this rule forbids is counting them as protection without dedicated assignment and verification. This rule makes no determination of any functional-safety level, does not specify the design or verification of interlocks and protection, and does not preemptively deny that a safety lifecycle may assign risk-reduction responsibility to an alarm system or an operator response — whether that assignment holds, and to what degree, is determined by the applicable functional-safety standards system, not by these guidelines (see the scope statement and Appendix B).

Design applicationIn design review, for every hazardous action "stopped by the interface," ask "what happens if this click goes through anyway" — if the answer lands on a personal-injury or equipment consequence, that action needs protection beyond the interface; when writing interface confirmations into design documentation, explicitly label them as a human-factors aid, not a protective measure.

Verification examples

• User side: force a mis-confirmation against an ordinary confirmation, and check whether the related protection still executes per the approved design.
• Implementation side: check the list of hazardous actions and confirm item by item that their blocking mechanism does not exist only at the interface layer; check for any protective item that was removed on the grounds of an interface prompt; for interface mechanisms claimed to carry a safety responsibility, check only for a reference to a dedicated assignment of responsibility and verification evidence — an interface review does not substitute for a safety assessment, and "containing a certified component" does not substitute for verification of the whole function.

CounterexamplesUnder-delivery — a constraint preventing two devices from starting simultaneously exists only in screen logic, and bypassing the screen via an engineering station or a local panel allows simultaneous starting; over-delivery — every interlock's reset entry point is removed from the operating screen in the name of "the interface must never participate in safety," and the operator, needing a normal reset, is forced onto an off-standard path, increasing bypass behavior instead.

Basis and referencesR15 records that a red emergency-stop button was shown on a tank-farm mimic diagram, and multiple on-duty staff did not know it had never been connected to the system. This is a publicly documented instance of a control on the interface not constituting protection; the rest of this rule is derived by working backward from the commitment, citing no functional-safety standard (see reference.md R15 and Appendix B.3).

IH5-4Permission and duty roles are enforced by a mechanismMUST¶

In one sentence: Permission is not hiding the button.

Applies tosystems that distinguish operating permission, duty role, or workstation responsibility.

RuleOperating permission MUST be enforced on the side that accepts the command, not implemented only by showing and hiding on the interface; the same command issued through another entry point (an engineering station, a configuration tool, a script, an interface call, a local panel) MUST be constrained by the same set of permissions. When permission is insufficient, the interface MUST state that it currently cannot be executed and what condition is needed, rather than letting the control silently fail or vanish without explanation. On-duty identity MUST be determinable: the system MUST be able to resolve, for every operation, the on-duty identity that issued it; a long-term shared account that cannot distinguish individuals MUST NOT be the sole means of tracing a critical operation. A temporary elevation of privilege MUST have a scope, a time limit, and a record, and MUST be automatically revoked on expiry.

Boundary conditionsThis rule does not specify an authentication method, nor does it require re-authentication on every operation — physical access to the control room combined with a workstation login is a reasonable combination in most sites. This rule does not address authentication and access-control requirements for industrial-network security — those must be assessed separately against applicable cybersecurity standards (see the scope statement). This rule does not forbid a shared workstation; what it forbids is a shared workstation making an operation unattributable.

Design applicationPut permission determination on the command-acceptance side, shared by every entry point; bind on-duty identity to the workstation login, so that switching identity at shift change is an explicit action rather than an optional one.

Verification examples

• User side: attempt a critical operation with a low-permission identity and check whether the interface states what condition is missing; issue the same command through another entry point and check whether it is equally rejected.
• Implementation side: inventory every entry point that can issue a control command and verify individually that permission determination takes effect; sample operating records for the proportion that cannot be resolved to a specific individual.

CounterexamplesUnder-delivery — a button is hidden on screen by permission, while the same command can be issued directly through an engineering-station debugging tool with no identity left behind; over-delivery — permission is sliced extremely finely and every cross-category operation requires re-login, so operators log in and share a single high-privilege account long-term to avoid being interrupted during disposition.

Basis and referencesR15 records that control-room permission settings allowed every on-duty staff member to change any parameter, including alarm setpoints. This rule does not address access-control requirements for industrial-network security — those must be assessed separately against applicable standards (see reference.md R15 and the guidelines' scope statement).

IH5-5Bypass, force, and privilege escalation leave a trace and are reviewedMUST¶

In one sentence: The record a high-consequence action leaves must actually be looked at by someone.

Applies tosystems that provide the capability to bypass, force, remove an interlock, mask an alarm, execute with elevated privilege, or set a parameter beyond its limit.

RuleThe above high-consequence actions MUST leave a record, containing who performed it, when, the object, the value or state before and after the action, the reason, and the expected recovery condition; the reason MUST NOT be filled with an empty value or a system default text. The record MUST be not silently deletable or alterable by the person who performed the action, and MUST be independently retrievable. The product MUST define who is responsible for reviewing these records and when — a record that no one looks at produces no effect from leaving a trace; the review result and any unrestored items MUST be able to enter the shift handover (IH6-3). A bypass or force currently still in effect is simultaneously governed by the list requirement in IH3-4: the record governs "what has happened," the list governs "what is still on right now," and neither substitutes for the other.

Boundary conditionsThis rule does not specify a retention period for the record or a review cycle — those are determined by the product against process consequence and applicable requirements, with the basis recorded. This rule does not require review to be carried out by a dedicated role, but it does require that responsibility be resolvable to a specific role. This rule makes no compliance determination.

Design applicationMake "reason" a required, structured field with selectable categories rather than a free-text box, so it can be tallied by category afterward; make "currently unrestored high-consequence actions" a fixed review entry point and handover item, rather than waiting for someone to go dig through logs on their own initiative.

Verification examples

• User side: pull up the high-consequence action records for a recent period and check for entries with a missing reason, entries unrestored for a long time, and evidence of review.
• Implementation side: attempt to delete or modify one of one's own records from the account that performed the action; check for any bypass path that writes no record.

CounterexamplesUnder-delivery — an interlock removal only changes a bit inside the controller, with no record anywhere in the system, and no one mentions it at shift handover; over-delivery — leaving a trace is turned into a form process requiring approval at multiple levels, so the operator cannot bypass in time during an emergency and instead has someone change it directly in the controller, and the record disappears altogether.

IH5-6A command's result is verifiable, and concurrent operations are adjudicatedMUST¶

In one sentence: When two people move the same pump at once, the adjudication must be explicit, and both sides cannot see "success."

Applies tosystems that issue control commands through the interface; concurrency adjudication additionally applies to situations where the same object can be operated from multiple entry points, including the control room, local panels, mobile terminals, and remote entry points.

RuleConcurrent operations on the same controlled object MUST have an explicit adjudication rule, and that rule MUST be visible to every party involved: who currently holds operating authority over that object, what other parties can currently do, and how operating authority is obtained and released. A situation MUST NOT occur where two entry points each believe their own command has taken effect while only one actually has — the party that was rejected or overridden MUST receive an explicit result. When one party's operation is taken over or overridden by another, the original party MUST be notified. The priority relationship between local operation and remote operation MUST be explicit and presented consistently on both sides (see also IH4-5).

Command submission or acceptance, controller execution result, equipment feedback, and the expected process effect MUST be expressed separately; where evidence is insufficient, retain "pending verification" or "result unknown," and none of the four MUST be used to impersonate the others — a protocol-layer write success is not the same as the valve being in position, and the valve being in position is not the same as flow having changed. A communication timeout alone is not sufficient proof that the action did not occur. A command that could repeat a physical effect (jog, feed addition, an accumulating increment, start/stop) MUST NOT be automatically resent before its state has been verified or a validated anti-repeat safeguard exists; a reconnection, a workstation switch, or a controller restart does not by itself authorize re-execution.

Boundary conditionsThis rule does not specify which adjudication method to use (exclusive holding, priority, or first-come-first-served are all acceptable), nor does it require operating-authority ownership to be set up for every object — a low-consequence object may go without it, but there MUST still be conflict adjudication and an explicit result on the acceptance side, determined by the product against consequence, with the basis recorded. This rule does not require that only one of two concurrent commands ever actually executes: if the acceptance side processes them serially per a stated adjudication — executing a start and then a higher-priority stop right after — both genuinely occurring does not violate this rule; what this rule requires is that the adjudication is explicit, each party's result is distinguishable, and the final state is not misreported. This rule does not address the implementation of network-layer concurrency consistency.

Design applicationMake operating-authority ownership a visible state of the controlled object, presented at the same layer as control mode (IH4-1); establish an explicit "field takes priority" or "control room takes priority" rule between a mobile inspection terminal and a control-room workstation, and let both sides see the current ownership.

Verification examples

• User side: arrange two operators to issue opposite commands to the same object at the same time from different workstations, and record the result each side sees and the action that actually occurs.
• Implementation side: check whether adjudication logic exists on the command-acceptance side, or whether mutual exclusion exists only at the interface; check whether a rejected command returns an explicit result to the initiator. Additionally construct the four situations "controller accepts but the actuator sticks," "an intermediate system returns an asynchronous success," "the action executed but the receipt was lost," and "repeated clicks after a disconnect-reconnect," and check whether the actual number of actions matches the result stated on the interface, rather than checking only whether the button is grayed out.

CounterexamplesUnder-delivery — the control room issues a pump stop while the field simultaneously presses start, both sides' interfaces show the operation succeeded, and the pump's actual state matches neither person's belief; over-delivery — to avoid conflict, the object-locking period is set very long with no way to force a release, and when one operator leaves the workstation no one else can take over, blocking disposition behind a single lock.

3.6 IH6 The shift is continuous¶

This principle governs the shift process itself, spanning time, people, and workstations. The regulated objects of the first five principles all sit within a single instant: how this value is presented right now, whether this alarm should fire right now, how this operation should be verified right now. But the process the operator faces does not conclude within a single instant — a matter may span three shifts, one person's judgment depends on what happened while they were not present, and a large screen and a workstation must divide labor rather than duplicate each other. Designing the interface as "one person, at one instant, facing one screen" is a systemic gap in this domain: it degrades shift handover into word of mouth, makes overnight monitoring depend on individual vigilance, and lets a screen revision take effect quietly while someone else is on shift. This principle's object is that continuous process.

IH6-1Drilling in and returning does not lose contextMUST¶

In one sentence: Clicking in to see detail should not get you lost.

Applies tosystems composed of multiple tiers of screens such as overview, area, and equipment.

RuleWhen entering a lower tier from a higher one, the basis for entering MUST be carried along: entering from a specific anomalous area on the overview, the screen reached MUST point to that area and the specific object that triggered entry, and jumping to a generic screen unrelated to the basis for entry MUST NOT occur. Returning MUST go back to the original position and the original observation state (the screen, time range, filter conditions, object of attention), not to a default home screen. The current position and its level within the whole MUST be obtainable, and the operator MUST NOT be required to rely on memory to maintain their position within the screen structure. Time range and filter conditions across screens SHOULD stay consistent within a single analysis session, and any change SHOULD be made explicit.

Boundary conditionsThis rule does not specify the implementation form of navigation (a hierarchy tree, a back stack, breadcrumbs, and side-by-side views are all acceptable), nor does it require direct reachability between any two arbitrary screens. This rule does not address the division of the screen hierarchy itself — that is IH1-5. The continuation of a working state across shifts is covered by IH6-6.

Design applicationMake "the current observation context" (object, time range, filter) an object that travels with navigation, rather than each screen maintaining its own default; when entering from an alarm entry, carry that alarm along as the basis for entry, so the destination screen points directly at the related object.

Verification examples

• User side: drill three tiers deep from one anomaly on the overview and then return, and record whether the time range and filter conditions need to be reset afterward.
• Implementation side: inventory the entry points for navigation, and check for any path that discards the basis for entry and jumps to a generic screen.

CounterexamplesUnder-delivery — clicking an alarm just opens the entire process screen the equipment belongs to, and the operator must still find which of dozens of graphic elements it is on their own; over-delivery — every jump carries and stacks all of the filter conditions from the tier above, and by the third tier the operator sees an empty screen filtered down layer by layer, with no clarity about what got filtered out.

IH6-2Shared displays and individual workstations have a clear division of laborSHOULD¶

In one sentence: The big screen is not the workstation screen enlarged.

Applies tosites where a shared display (a control-room large screen, a crew dashboard) and individual workstations coexist.

RuleA shared display and an individual workstation SHOULD carry different responsibilities, each stated explicitly: the shared display serves context jointly held by the crew — whether things are normal overall, where an anomaly is, and what dispositions are currently in progress; the individual workstation serves what this particular person is currently doing. Content that can only be read or read clearly from a specific workstation seat MUST NOT be presented on the shared display; its readability SHOULD be verified at actual viewing distance and angle, not designed to workstation viewing conditions. Shared-display content SHOULD NOT be changed arbitrarily by one person's action; where switching is genuinely needed, the switch SHOULD be visible to those present and able to return to default. A shared display is equally governed by IH3-3: when it stops refreshing, that MUST be noticeable.

Boundary conditionsThis rule does not require a shared display to be provided; a site with no shared display records "not applicable." This rule does not specify the number of screens or the layout of a large display. The division of labor between a mobile inspection terminal and a control-room workstation is not covered by this rule; its operation adjudication is in IH5-6.

Design applicationFirst write down "what the crew needs to see together," then decide what the large screen shows; design large-screen content as a presentation that holds without interaction, rather than an enlarged, operable interface.

Verification examples

• User side: at the actual viewing position, ask crew members to read out the large screen's key information, and record items misread or unreadable.
• Implementation side: check whether the large-screen content has a stated responsibility, whether its readability has been verified against actual viewing conditions, and whether it is noticeable when it stops refreshing. Content matching a workstation screen does not by itself constitute a violation — responsibility, readability, and state continuity are this rule's criteria.

CounterexamplesUnder-delivery — the large screen is simply a workstation screen projected up, and someone sitting in the back can only see a patch of color, so the crew's shared context does not actually exist; over-delivery — the large screen is built as an independent system requiring remote operation, and during an anomaly no one is willing to get up and operate it, so it sits for a long time on an unrelated screen.

IH6-3A shift handover has a verifiable set of handover itemsMUST¶

In one sentence: What gets handed over is the unfinished business, not the word "normal."

Applies tosites with continuous duty and a shift handover.

RuleThe system MUST be able to generate a verifiable list of handover items, covering at least: alarms currently suppressed or shelved (IH2-4), points currently forced, bypassed, or in simulation (IH3-4), objects currently in a non-normal control mode (IH4-1), high-consequence actions that occurred during this shift and their unrestored items (IH5-5), and unfinished anomaly dispositions (IH6-6). Handover MUST be an explicit action by both parties: the incoming operator confirms receipt, and the handover time and both identities are recorded. The handover list MUST NOT degrade into a piece of free-text notes — notes may exist, but they do not substitute for the verifiable items above. Every item in the handover list MUST be traceable to its source state, not a one-time snapshot of text.

Sign-off MUST correspond to the content actually checked: record the set of items verified at this handover and the time, while retaining a link to the current source state. A bypass, alarm, operating authority, or pending command that is added or changes during the check MUST be presented to the incoming operator as a difference, and MUST NOT be automatically overwritten by a stale sign-off. Transfer of responsibility and transfer of operating authority are confirmed separately; a refusal, a timeout, or an interruption MUST NOT turn a matter into something no one is responsible for, nor MUST browsing the list be treated as handover complete.

Boundary conditionsThis rule does not specify the organizational form or duration of handover, nor does it require the system to replace verbal handover — the judgment and expectation conveyed verbally is something a list cannot carry; what this rule requires is that the list is missing no item. This rule does not specify the ordering or presentation of list items.

Design applicationGenerate the handover list from live system state rather than have it assembled by hand; provide an entry point into detail for every item, so the incoming operator can verify it in place rather than reading only a one-line summary.

Verification examples

• User side: complete a handover while several shelved alarms and forced points exist, and check whether the incoming operator can find and verify every item on the list.
• Implementation side: create all five categories of handover item and confirm each one automatically enters the list; check for any state category that is conveyed only verbally and is not visible to the system.

CounterexamplesUnder-delivery — the handover record reads only "running normally," and two alarms shelved by the previous shift and one unrestored bypass are discovered only two shifts later; over-delivery — the list itemizes every single event of the shift, requiring hundreds of records to be paged through at handover, and the incoming operator skims past the list as a whole.

IH6-4Prolonged monitoring does not rely on sustained vigilanceSHOULD¶

In one sentence: Do not count on a person staring at a motionless screen for eight hours.

Applies toduty positions whose primary task is continuous monitoring with long stretches of no event.

RuleThe product SHOULD NOT take "the operator will continuously notice minor changes on screen" as a design premise. For deviations that need to be noticed, the product SHOULD provide a noticing path that does not depend on sustained gazing (the intensity allocation of IH1-1, the alarm channel of IH2, or another proactive presentation); a critical deviation carried only by a slowly changing value MUST NOT be the sole means of noticing it. The product SHOULD enable the operator to obtain, between leaving and returning, "what happened during the time I was away" — on return, the state changes, alarms, and operations within that period MUST be obtainable. Night shifts, long shifts, and low-event-rate scenarios SHOULD be included in the design and verification scenarios, rather than designing only to a day-shift level of attention. Forced interaction (a timed click, a periodic acknowledgment) MUST NOT be used as the sole means of sustaining vigilance, nor MUST this rule be considered satisfied on that basis alone.

Boundary conditionsThis rule does not forbid the use of a duty-acknowledgment-type mechanism — it has a role in some sites; what this rule forbids is using it as a substitute for a noticeable presentation design. This rule does not specify shift scheduling, rest policy, or staffing — those belong to a site's operational management and ergonomics (see the scope statement). This rule gives no numeric figure for attention decay over time.

Design applicationFor every category of deviation that needs to be noticed, explicitly write down "what it is noticed by" — where the answer is "the operator will see it," redesign it; make "what happened while away" an obtainable review of the period, rather than requiring the operator to page through the complete history.

Verification examples

• User side: inject a slowly developing deviation during a long, low-event-rate period, and record the time to notice and the cue relied on.
• Implementation side: inventory the categories of deviation that need to be noticed, and confirm individually that their noticing path is not "sustained gazing at a value."

CounterexamplesUnder-delivery — a slowly rising level has no limit configured at all, on the design assumption that the operator will see it on the trend, and in practice no one notices across three consecutive shifts; over-delivery — an on-duty acknowledgment that must be clicked pops up every fifteen minutes, and the operator develops a mechanical response, dismissing it just as mechanically when a genuine response is actually needed.

Basis and referencesR19, citing vigilance research, notes that people find it difficult to sustain effective visual attention over long periods on an information source that changes very rarely, and notes that "a person can copy down a number without attending to its meaning"; R09 states that an operator must monitor low-frequency events over long shifts; R23 reports a measurable, linear-component decline in vigilance with task duration. R23 is a study of an abstract laboratory task, not a control-room study, and these guidelines therefore give no duration figure on this basis (see reference.md R19, R09, R23).

IH6-5Interface and configuration changes during a shift are controlledSHOULD¶

In one sentence: Do not quietly swap the screen while someone else is on shift.

Applies tosystems where screens, alarm configuration, limits, permissions, and automatic functions can be modified during operation.

RuleA change affecting operator judgment or method of operation — screen layout and graphic-element meaning, alarm addition/removal and limit adjustment, priority re-leveling, permission changes, changes to an automatic function's scope of service — SHOULD be known to on-duty staff before it takes effect, with the change content and effective time obtainable. The semantics of a screen or the position of an operating entry point an operator is currently using MUST NOT be silently changed while that operator is in the middle of an anomaly disposition. A change SHOULD leave a record traceable to its initiator; after a change, it SHOULD be possible to confirm that the operator has been made aware of it, especially for a change taking effect across a shift boundary (see also IH6-3). A change MUST NOT cause an ongoing disposition to lose its original entry point. A rollback path SHOULD exist and be executable during a shift.

Boundary conditionsThis rule does not require every change to be notified in advance — an immediate fix correcting an obvious error may be executed first and reported after, but it must still leave a trace and be reported. This rule does not specify the organizational process or approval level for change management — that belongs to the site's management system.

Design applicationMake "which screens, which alarms, which operating entry points a change affects" a required field at change submission, from which the system generates the notification to on-duty staff; display the change's effect and effective time so the operator can judge what has changed on the current screen.

Verification examples

• User side: after an alarm-limit adjustment that takes effect across a shift boundary, ask the incoming operator whether they are aware of the adjustment and its content.
• Implementation side: check for any configuration-modification path that produces no record and no notification (a direct edit at an engineering station, an offline configuration download, a bulk script modification).

CounterexamplesUnder-delivery — engineering staff adjust the limits of dozens of alarms during the day shift and download directly, and the night-shift operator discovers alarm behavior has changed with no idea what happened; over-delivery — even a single text correction is turned into a change notification requiring confirmation by everyone, and the operator becomes numb to change notifications overall, so the one change that genuinely affects judgment is skipped over as well.

IH6-6The working state of an anomaly response can be continuedMUST¶

In one sentence: If something is not finished when a shift ends, it must have somewhere to go.

Applies tosystems with anomaly disposition, diagnosis, or tracking tasks that may span more than a single duty period.

RuleAn unfinished anomaly disposition MUST be able to continue as a stateful object, rather than disappearing when the operator leaves the workstation. That object MUST at least make obtainable: the anomaly it corresponds to, what stage it is currently at, what has already been done, what it is currently waiting on, and who is responsible for it. It MUST be able to enter the handover list (IH6-3) and remain continuous once the incoming operator takes over, and the incoming operator MUST NOT be required to reconstruct the disposition process from raw records. When a disposition involves a shelved alarm, a bypassed signal, or a forced point, those items MUST be associated with that disposition object, so that their recovery condition does not depend on individual memory.

Boundary conditionsThis rule does not require the system to take on the responsibilities of existing management systems such as work orders, maintenance, and work permits — where a corresponding system already exists, what this rule requires is that the disposition state and its associated items are obtainable and not lost, which the existing system may carry. This rule does not specify the staging or naming of a disposition object. This rule does not require a disposition object to be created for every minor anomaly; what falls within scope is determined by the product against consequence and duration, with the basis recorded.

Design applicationMake "anomalies currently being disposed of" a visible list alongside the alarm list, rather than scattered across individual notebooks; attach the recovery conditions of a shelve, bypass, or force to the corresponding disposition object, so they can be checked together when the disposition ends.

Verification examples

• User side: perform a handover during a disposition that is not yet finished, and record how long it takes the incoming operator to grasp current progress and whether they need to call the previous shift to ask.
• Implementation side: check whether a disposition object stays linked to its associated shelved and bypassed items; check whether a disposition object still exists after a workstation logout and a system restart.

CounterexamplesUnder-delivery — a night shift's tracking of rising vibration on a machine pump is recorded only in a personal notebook, mentioned verbally at handover, and the day shift starts judging from zero again; over-delivery — a complete disposition record with stage-by-stage fields is required for every minor anomaly, and the operator abandons the mechanism when busy, so the one disposition that genuinely needs continuity also goes unrecorded.

4. Terminology and definitions¶

This chapter defines only the terms used within these guidelines that are prone to ambiguity. Terms of art in control engineering and functional safety follow the definitions of the applicable standards and codes; the explanations in this chapter serve only to understand the clauses of these guidelines, and do not constitute a redefinition of those terms.

5. From design decisions to acceptance evidence¶

5.1 Minimum delivery records¶

Every project completes the following records to the extent of its actual capability. Filling in a token only proves the decision has been recorded; it cannot prove the control mechanism or operator performance has passed verification.

The design MUST cover normal operation, startup/shutdown, anomaly, maintenance, loss-of-contact recovery, and handover within the declared scope; unsupported tasks are explicitly excluded, and complete coverage of a position MUST NOT be claimed by showing only the normal-operation screen.

5.2 Verify three categories of fact separately¶

Every test case records at minimum: the object and operating condition, the fault or trigger, the actual input, the expected and actual result, the measured start and end events, any mis-operation or omission, the location of evidence, and the person who made the determination. Time-to-notice is measured from the moment the anomaly holds true at the authoritative source, with acquisition, transmission, presentation, and human-response time recorded separately; timing MUST NOT start only when a pop-up appears, ignoring the delay before it.

5.3 Thresholds do not offset one another¶

1. Prohibited behaviors: a bad value impersonating a normal real-time value, an unauthorized critical command taking effect, an action repeated after its result is unknown, a stale acknowledgment overwriting a new alarm, continuous manipulation not ending on loss of contact. Any one of these occurring in a test within the declared scope of applicability is a failure, and no other metric offsets it.
2. Task performance: success rate and time for locating an anomaly, understanding mode, identifying the object, and completing the correct action. The project states its targets, sample, and rationale before testing; missed dispositions and incorrect target selection are itemized separately and MUST NOT be hidden within an average time.
3. Response time: total elapsed time across alarm detection and transmission, presentation, human judgment and action, and necessary equipment and process response, MUST fall within the available response window with a documented margin retained. Where this cannot be achieved, adjust the assignment of responsibility, control, or protection design — not merely raise the intensity of sound and color.
4. Sustained operation: duty load, repeated alarms, commands pending verification past their window, long-standing interventions, and unhandled-over items all have a responsible party and follow-up disposition, and fault-recovery paths are actually usable.

The conclusion is one of "passes within declared scope," "restricted use," or "does not pass." Restricted use MUST state the actual limitation and the substitute safeguard, for example a read-only terminal with a separate, already-validated control and alarm path; a passing condition MUST NOT be manufactured by disabling necessary alarms, clearing existing interventions, or having the operator monitor from memory. An in-service system MUST NOT be automatically shut down, have its protection disabled, or have its operating state erased merely because one configuration check failed.

5.4 Check for omission and over-design at the same time¶

An anomaly must be discoverable, and it must also be tested whether the normal state stays quiet and readable; a critical action must be verifiable, and it must also be tested whether routine fine adjustments are slowed down by repeated confirmation; a frozen screen must have an indication, and it must also be tested whether that indication blocks an entry point for a disposition still in effect; a handover must be complete, and it must also be tested whether a key difference can be found within routine records. When a representative task or environmental condition changes, re-check the affected evidence; actual missed detections, mis-touches, failed takeovers, and unrestored interventions feed into subsequent verification scenarios.

Appendix A: Fault-injection verification checklist and classification check¶

This checklist verifies whether the clauses actually take effect; it adds no new obligation. Inject item by item and record the system's actual behavior; recording "not applicable" is a valid result, recording "not tested" is not. Injection tests MUST be conducted without affecting actual production or personnel safety — carried out in a simulation environment, a standby system, or an approved shutdown window; this appendix is not a basis for conducting these tests on an in-service plant.

A.1 Presentation and readability

A.2 Alarms

A.3 Data trustworthiness

A.4 Mode and takeover

A.5 Operation and authorization

A.6 Continuity of duty

A.7 Combined faults and complete tasks

A.8 Classification check

Used to verify whether the split in Chapter 1 holds: take 10 to 15 concrete requirements (drawn from these guidelines' own clauses, or from actual review comments and incident-investigation findings), and have at least three reviewers who did not participate in writing these guidelines independently judge which principle each belongs to. When attribution disagreement concentrates between a particular pair of principles, that shows the regulated objects of those two principles have not been split apart — at that point the principles should be adjusted, rather than adding an intermediate layer or a mapping note. The two boundaries known to need priority testing are stated explicitly in Chapter 1 (IH1 and IH3, IH4 and IH5). The reviewer count and the disagreement criterion are an internal check method these guidelines propose, not a standard method validated by literature.

Appendix B: Evidence boundaries and source types¶

B.1 Criteria for normative terms

The sole basis for marking something "MUST" is: without it, some commitment to the operator would fail under foreseeable conditions. The three categories of evidence below provide different kinds of support; they are not three independent sources of mandate — the existence of an industry standard, or the fact that some product has done it this way, is not by itself sufficient to warrant marking something "MUST" —

The eight rules marked "SHOULD" (IH1-4, IH2-6, IH3-5, IH3-6, IH4-6, IH6-2, IH6-4, IH6-5) are all matters of trade-off, not matters of a hard floor: a deviation may have legitimate reason, but it must leave a trace and accept the same verification. Several of them contain forbidding-level clauses (see 2.2); the clause itself remains a hard constraint.

B.2 The three thinnest points of evidence in these guidelines

Listed explicitly, not masked by the tone of a clause:

1. IH2-2 gives no alarm-load figure of any kind. The benchmark values circulating in public literature and industry practice carry premises about their survey scope, plant type, and counting convention, and no verifiable primary basis was obtained this time to support any universal figure. These guidelines therefore only require "the target be explicitly defined, have a basis, be measured, and be used in decisions." Accordingly, IH2-2 requires target reasonableness to be verified in conjunction with complete response time and missed-disposition data (source R26, R31); Chapter 5 defines how evidence is recorded — relaxing the target cannot substitute for verification.
2. The noticing path in IH6-4 lacks verifiable evidence of effectiveness. That prolonged, low-event-rate monitoring weakens the capacity to notice is discussed in the research; but there is no conclusion about "which category of presentation is effective over how long a shift" that can be directly transplanted to a specific plant. These guidelines only require that the noticing path not be "sustained gazing," without making an effectiveness promise about any substitute.
3. The allocation of presentation intensity in each IH1 rule lacks a cross-scenario quantitative basis. "Normal is quiet, abnormal stands out" has broad engineering consensus as a direction, but the concrete division of intensity tiers, contrast values, and their performance under different field-illuminance conditions must be measured by the product itself. These guidelines give the criterion for the allocation relationship, not a directly adoptable visual parameter.

B.3 What these guidelines do not do

They make no determination or certification of functional-safety level, do not specify the design or verification of interlocks and protection functions, do not specify process design or control algorithms, make no compliance assessment of industrial cybersecurity, do not specify hardware and environmental protection ratings, do not specify the control room's architectural and ergonomic layout, personnel qualification, or training certification, give no concrete figures for alarm rate, response deadline, contrast, or refresh cycle, do not specify configuration software, communication protocols, or screen-building tools, and give no color scheme or control appearance. These are decisions for the standards system, engineering disciplines, and the product; these guidelines specify only that the decisions relevant to the operator's monitoring and operating experience MUST be made, MUST be testable, and which values are not permitted. Adopting these guidelines does not constitute any proof of compliance.

B.4 Sources

The complete source catalog, verification status, and retrieval record are in reference.md. The full text of most relevant standards is behind paywalled access, and the original text was not obtained this time; reference.md distinguishes public sources that were read, records of existing material, and leads pending verification. A clause in these guidelines does not hold merely because some standard exists, nor merely because some vendor has done it this way; a source proves that this kind of mechanism or this kind of failure exists, and does not directly prove that a given requirement applies to every product.

---

Implementation acceptance scenarios¶

The scenarios below turn the existing clauses into reviewable acceptance input, without setting any additional general-purpose performance threshold. Select per the product's applicable capability, supplementing actual equipment, users, input sequences, and evidence; record the reason where not applicable, and an item not executed MUST NOT be recorded as passed.

Each scenario separately verifies the configuration's effective value, the execution record, and a result the user can understand. Retain the version, target, event timing, failure scope, and recovery result; where an external result is unknown, it is not filled in as either success or failure.