Conformance statement
ISA-18.2 Conformance
Scope
ANSI/ISA-18.2 covers the whole alarm lifecycle in ten stages: the alarm philosophy document, identification, rationalisation, detailed design, implementation, operation, maintenance, monitoring and assessment, management of change, and audit. Most of these are organisational activities whose deliverables are documents rather than software.
A component library cannot conform to ISA-18.2 by itself. The components implement the operator-facing part of the operation and monitoring stages and do not interfere with the other stages. This page lists what is implemented, so that a reference to ISA-18.2 alarm management can be checked.
| Lifecycle stage | Provided by the components |
|---|---|
| 1. Philosophy | Nothing. A document your organisation writes. |
| 2. Identification | Nothing. |
| 3. Rationalisation | Nothing. Priority assignment, consequence and response time are yours; the components render the priority you supply and never assign one. |
| 4. Detailed design | The HMI portion. Priority presentation, state indication, and the operator actions available. |
| 5. Implementation | Nothing. Configuration and commissioning of the alarm system itself. |
| 6. Operation | The operator interface. The alarm summary, the banner, the annunciator panel, acknowledgement, shelving. |
| 7. Maintenance | Partial. Out-of-service state is represented and reported; taking a point out of service is the application's write. |
| 8. Monitoring and assessment | Partial. Live counts by state; flood detection lives in Smart.Industrial.ai, not in the alarm components. Historical performance metrics are the application's. |
| 9. Management of change | Nothing. |
| 10. Audit | Nothing. The components hold no history and write no records. |
The alarm state model
smart-alarm-grid implements the ISA-18.2 state model as a pure
function, Smart.AlarmGrid.stateOf(alarm, now), so it can be tested and
reused without instantiating a grid. Seven states:
| State | Condition |
|---|---|
out-of-service | Removed from service for maintenance. Outranks everything, that is what taking a point out of service means. |
suppressed | Suppressed by design. Outranked by out-of-service: a maintenance decision beats a design decision. |
shelved | Shelved by an operator and not yet expired. shelveDuration defaults to 30 minutes; expiry is evaluated against the reference time, so it is testable and cannot silently persist. |
unacknowledged | Active, not acknowledged. |
acknowledged | Active, acknowledged. |
rtn-unacknowledged | The condition cleared on its own and nobody ever looked at it. |
normal | Cleared and acknowledged. |
The rtn-unacknowledged state is important. Many alarm list implementations drop a row as soon as the condition clears. An intermittent fault then leaves no trace: the alarm is raised, clears before the operator sees it, and disappears. The components keep the row in the summary until it is acknowledged, and Smart.AlarmGrid.isOutstanding(state) reports it as still requiring a response.
The precedence of the states defines the result when several conditions are true at the same time. Operator and engineering overrides take precedence over the process condition.
The components report and do not modify alarms
acknowledge(), acknowledgeAll(), shelve(), unshelve(), suppress() and outOfService() each raise an event and return. None of them changes the alarm. The application sends the action to the control system, and the component updates when the new state is reported.
An operator who presses acknowledge and sees the row change state has been told that the alarm system accepted the acknowledgement. If the write was rejected or the connection was down, the screen would show a state that is not true, and an acknowledgement is a recorded operator action. smart-alarm-banner and smart-faceplate follow the same rule.
Presentation
- Priority is displayed, not assigned. Priority 1 is shown as critical, 2 as warning and 3 as advisory; the alarm grid draws 4 and above as a fourth band, and the alarm banner also takes a
severityon the record, which overrides the one its priority gives. - Colour is not the only indicator. In the alarm grid the priority is a number in its own column, the priority band has a shape as well as a colour, and the state is a word in the State column (shown by default), so both are available to an operator who cannot distinguish the colours. ISA-18.2 requires alarms to be distinguishable; this meets the requirement for more than one kind of operator.
- The banner shows the highest-priority unacknowledged alarm and keeps it in view, which meets the requirement that the most important alarm is always visible.
- The annunciator implements the ISA-18.1 tile states (
normal,alarm,ackandringback) for sites that present alarms as a tile wall. - Counts by state are available from
counts(), which is the operator-facing part of monitoring. The grid announces new alarms (how many are outstanding and the highest priority among them) when their number rises; it does not announce the counts by state.
Known limitations
- No alarm history and no audit trail. The components hold the alarms they are given. Retention, sequence-of-events recording and operator action records are provided by the application, and stage 10 of ISA-18.2 cannot be met without them.
- No flood detection in the alarm components. The ISA-18.2 flood condition (more than ten alarms in ten minutes per operator) is computed by
Smart.Industrial.ai, which is a separate module. The alarm grid does not detect or indicate a flood on its own. - No dynamic or state-based alarming. Suppression by design is represented as a state; the decision to suppress an alarm based on the unit state or mode is made by the alarm system.
- No deadband, delay or shelving policy enforcement.
shelveDurationis a default, not a limit. ISA-18.2 expects shelving to be limited and reviewed; the component shelves an alarm for as long as it is told to. - Performance at flood scale depends on the table. Measured on the performance page: assigning 10,000 alarms and deriving their states took about 1.6 seconds on the test machine, most of it in the underlying
smart-table, whilecounts()over the same 10,000 took under a millisecond. For a summary that has to stay responsive during a flood, limit the number of rendered rows and page the rest.
Related: the WCAG 2.2 AA conformance report covers the accessibility of these same components.