HMI, SCADA, Historians and Alarm Management

Introduction

Industrial automation is not complete when a PLC executes its control logic. Operators must understand process conditions, detect abnormal situations, make timely decisions, and record what occurred. Human–machine interfaces (HMIs), supervisory control and data acquisition (SCADA) systems, historians, reports, recipes, and alarm systems form the information layer between field equipment and human decision-making.

A poorly designed interface can hide a dangerous condition even when the control system is functioning correctly. An alarm system that produces hundreds of messages during a disturbance can prevent operators from recognizing the few alarms that matter most. A historian that stores unreliable or poorly contextualized data can make troubleshooting and regulatory reporting difficult. Consequently, these systems must be designed as engineered systems, not merely as collections of screens and software tags.

This chapter applies human-factors principles and the intent of ISA-101 to HMI design, ISA-18.2 principles to alarm management, and sound information-management practices to SCADA and historian systems.

Learning Objectives

After studying this chapter, the reader should be able to:

1. Explain the roles and relationships of HMI, SCADA, PLC, historian, and alarm-management systems.
2. Design operator displays using hierarchy, consistency, context, and human-factors principles.
3. Distinguish process control, supervisory control, monitoring, reporting, and data archival.
4. Configure trends, reports, recipes, and historical data with appropriate context and quality information.
5. Apply the alarm-management lifecycle, including rationalization, prioritization, shelving, performance monitoring, and change control.
6. Analyze a practical automation scenario and propose an improved operator interface and alarm strategy.

1. Automation Information Architecture

A typical industrial information architecture contains several levels:

The HMI is the operator’s visual and interactive interface to the control system. SCADA generally adds supervisory data acquisition, centralized monitoring, event handling, remote commands, and communications across geographically distributed equipment. The terms overlap in practice: a plant HMI may be part of a SCADA platform, while a SCADA system may contain many local HMIs.

A historian is a time-oriented database optimized for process values, states, events, and associated metadata. Unlike a conventional transaction database, it commonly uses compression and time-series retrieval methods. A historian should preserve not only a value, but also its timestamp, quality, engineering unit, source, and sometimes operating context.

The control system should remain capable of maintaining safe operation when the supervisory computer or network is unavailable. An HMI is normally not the primary safety layer, and a historian must never be treated as a real-time control device.

Figure: Functional layers of an industrial automation information architecture.

2. HMI Design and Human Factors

2.1 The operator’s task

An operator typically performs four cognitive activities:

1. Perception: determining what is happening.
2. Diagnosis: identifying why it is happening.
3. Decision: selecting a suitable response.
4. Action and verification: issuing a command and checking its result.

An effective HMI supports this sequence. It does not merely display every available tag. Excessive detail increases search time and cognitive load, while insufficient context makes diagnosis difficult.

2.2 Display hierarchy

A practical display hierarchy includes:

• Overview display: plant-wide production state, major constraints, abnormal areas, and key performance indicators.
• Area display: relationships among major units and flows.
• Unit or process display: equipment status, measurements, control loops, and active alarms.
• Detail display: valve faceplates, interlocks, permissives, tuning information, and diagnostic data.
• Maintenance and diagnostic displays: I/O health, communications, device status, and fault codes.

The operator should be able to navigate from an abnormal indication to its cause without excessive screen changes. Navigation should be predictable, with consistent locations for equipment status, alarms, modes, trends, and commands.

2.3 ISA-101 concepts in practice

ISA-101 provides a lifecycle-oriented framework for effective HMI design and management. Its important practical ideas include a documented philosophy, standardized display conventions, user-centered design, verification, validation, and lifecycle maintenance.

A useful HMI philosophy specifies:

• display hierarchy and navigation;
• color, symbol, and text conventions;
• equipment faceplate behavior;
• alarm presentation;
• access levels and command confirmation;
• use of animation and sound;
• standards for trends, units, decimal places, and status indication;
• procedures for testing and approving displays.

2.4 Color, shape, and attention

Color should communicate abnormality or priority rather than decorate the display. A neutral background with restrained color generally makes abnormal conditions more conspicuous. Red may indicate a high-priority alarm, but it should not be used simultaneously for ordinary piping, selected objects, and unrelated status conditions.

Color must not be the only means of conveying meaning. Operators with color-vision deficiencies and operators working under poor lighting must still be able to interpret the display. Text, shape, position, line style, and symbols should provide redundant information.

Animation should be reserved for conditions requiring attention, such as a rotating equipment symbol showing actual motion. Constantly moving graphics can distract operators and make a screen harder to scan.

2.5 Controls and commands

A command should clearly identify:

• the equipment affected;
• the requested action;
• current state;
• permissives and interlocks;
• consequences of the command;
• whether confirmation is required.

Critical commands should use role-based access, confirmation, and an audit trail. Confirmation dialogs are useful for consequential actions, but excessive confirmation creates habituation and may encourage operators to click through warnings.

A control should show command feedback. For example, after an operator commands a motor to start, the display should distinguish “start command issued” from “motor running.” The latter should be based on feedback such as an auxiliary contact or measured speed.

3. SCADA Functions

SCADA systems commonly provide:

• communication with PLCs, RTUs, and intelligent devices;
• real-time visualization;
• command and control supervision;
• alarm and event management;
• user authentication and audit trails;
• trends and reports;
• redundancy and failover;
• interfaces to historians and enterprise systems.

SCADA communication may be polling-based, event-driven, or a combination. Communication design must account for update rates, bandwidth, latency, time synchronization, failure behavior, and buffering. A displayed value should identify whether it is current, stale, bad quality, substituted, or unavailable.

Remote commands require particular care. The system should prevent ambiguous control authority, such as two stations simultaneously controlling the same asset. Local/remote selection, command arbitration, permissive logic, and loss-of-communications behavior should be explicit.

Cybersecurity is part of SCADA engineering. Good practice includes network segmentation, least privilege, secure remote access, patch and vulnerability management, application allow-listing where appropriate, backups, logging, and tested recovery procedures. Security controls must be balanced against availability and the need for rapid response during an abnormal situation.

4. Trends, Reports, Recipes, and Context

4.1 Trends

A trend is useful when it supports a question: Is temperature rising? Did the valve respond? Was the process stable before the trip? A trend should therefore provide:

• clearly labeled variables and units;
• a meaningful time range;
• distinguishable traces;
• engineering limits and alarm limits where useful;
• cursor or inspection capability;
• indication of bad or missing data;
• appropriate sampling and aggregation.

The plotting interval should not imply precision that the measurement system does not possess. A historian may store a value every second, but the sensor accuracy, process dynamics, and control scan time determine whether that resolution is meaningful.

For a sampled signal xᵢ, the arithmetic mean over n valid samples is:

Here, x̄ is the mean in the same engineering unit as xᵢ, n is the number of valid samples, and the summation includes only samples meeting the defined quality criteria. The formula assumes samples represent the intended interval; it is not automatically appropriate for irregularly sampled data or for totalizing flow.

For irregular time intervals, a time-weighted mean is more appropriate:

where ∆tᵢ is the duration represented by sample xᵢ. Both numerator and denominator have compatible time units, so x̄ₜ retains the unit of x.

4.2 Historian storage and compression

Historian compression reduces storage and communication requirements while preserving significant process changes. A deadband defines a value change below which a new sample may not be stored. A time deadband prevents excessive storage when values change rapidly but insignificantly. Compression must never remove information needed for alarm reconstruction, batch records, compliance, or safety analysis.

Each tag should have metadata such as tag name, description, unit, source, scan or sampling rate, engineering range, scaling, quality rules, compression settings, and retention period. Time synchronization using a reliable plant time source is essential because event sequence analysis depends on correct ordering.

4.3 Reports and performance indicators

Reports convert data into decisions. Examples include production totals, downtime causes, energy intensity, batch yield, alarm performance, and maintenance history. A report should define its calculation period, data-quality rules, exclusions, and responsible owner.

A common availability measure is:

where both times use the same unit and the planned period is explicitly defined. If planned production time is 480 min and operating time is 450 min, availability is 450 ÷ 480 = 0.9375, or 93.75%. Availability alone does not explain quality losses, speed losses, or the reasons for downtime.

4.4 Recipes

A recipe is a controlled set of parameters, materials, sequences, and instructions used to produce a defined product or batch. A robust recipe system includes version control, approval status, effective dates, user authorization, parameter limits, download verification, execution history, and rollback or recovery procedures.

Recipe values must not silently overwrite operator-entered data. The system should distinguish an approved master recipe from an execution instance and should record who changed what, when, and why.

5. Alarm Management

5.1 Definition and purpose

An alarm is an audible and/or visible indication of an abnormal condition requiring operator response within a defined time. An alarm is not merely an event, status message, or maintenance notification. If no operator action is required, the condition may belong in an event log or diagnostic display rather than the alarm list.

A useful alarm statement identifies:

• the abnormal condition;
• the consequence if no action is taken;
• the required operator response;
• the time available for response;
• the responsible operator or role.

5.2 The alarm-management lifecycle

The lifecycle commonly includes philosophy, identification, rationalization, detailed design, implementation, operation, maintenance, monitoring, management of change, and periodic audit. Alarm management is continuous because process conditions, operating practices, equipment, and control strategies change.

During rationalization, each proposed alarm should be tested against questions such as:

1. Is the condition abnormal and consequential?
2. Can the operator influence the outcome?
3. Is operator action required rather than automatic control action alone?
4. What is the consequence of failure to respond?
5. What is the required response time?
6. What priority and limit are justified?
7. Can the alarm be removed, suppressed, or replaced by better control logic?

5.3 Priority and alarm settings

Priority should reflect consequence and time to respond, not equipment prestige or the designer’s preference. A high-priority alarm should be uncommon and clearly more urgent than a low-priority alarm.

Alarm limits must account for measurement uncertainty, process variability, control response, and operating constraints. A high alarm setpoint should not be so close to normal variation that nuisance alarms result. Conversely, a wide limit that provides inadequate response time is unsafe.

For a process variable with a high alarm limit L, an alarm is logically active when the valid measured value x satisfies x ≥ L, subject to configured delay, hysteresis, and quality rules. Hysteresis h prevents repeated transitions near the limit. For a high alarm, the alarm may clear only when:

where h has the same unit as x and is nonnegative. Hysteresis should be large enough to prevent chattering but small enough not to delay recognition of a genuine return to normal.

5.4 Alarm states and operator actions

Important states include active-unacknowledged, active-acknowledged, cleared-unacknowledged, and cleared-acknowledged. Acknowledgement means the operator has recognized the alarm; it does not mean the abnormal condition has been corrected.

Shelving is a temporary, authorized suppression of an alarm. It should have a reason, duration, user identity, and review mechanism. Shelving must not become a permanent substitute for correcting bad alarm design.

Alarm floods occur when the rate of incoming alarms exceeds the operator’s ability to assess and respond. Flood analysis should identify initiating events, consequential alarms, chattering alarms, standing alarms, and alarms that provide no useful action. Suppression, state-based alarming, deadbands, delays, improved control, and better alarm rationalization can reduce floods.

5.5 Alarm performance metrics

Useful metrics include alarm rate per operator, standing alarms, chattering alarms, stale alarms, percentage of alarms acknowledged, and distribution by priority. Metrics should be interpreted with operating context; a low alarm count achieved by excessive suppression is not necessarily good performance.

A simple alarm rate is:

where Rₐ is alarm rate, Nₐ is the number of alarm occurrences, and T is the observation time. If 120 alarm occurrences occur during a 2-hour period, Rₐ = 60 alarms per hour. This metric assumes that the counting rule and observation period are clearly defined. It does not by itself measure alarm usefulness or operator workload.

6. Applied Case: Illustrative Mixing Plant

Background

Consider an illustrative batch mixing plant producing two liquid products. Three tanks contain agitators, heating elements, level transmitters, temperature transmitters, and automated valves. A PLC controls sequences, while an HMI supervises two production areas. Historical data are required for quality investigations.

Problem

Operators report that the overview screen is crowded, tank colors are inconsistent, and alarms frequently occur during product changeover. The historian contains temperature values but not recipe number, batch phase, or operator actions. During one incident, a high-temperature alarm was acknowledged but the operator did not notice that the heater remained on because the alarm cleared when the transmitter briefly failed.

Analysis

The investigation identifies four issues:

1. The interface does not separate normal status from abnormal conditions.
2. Alarm quality failure is not distinguished from a genuine return to normal.
3. Changeover alarms are not evaluated by operating state.
4. Historical data lack contextual information.

Approach and solution

The team develops an HMI philosophy and redesigns the displays. The overview shows production state, tank levels, active high-priority alarms, and equipment availability. Unit displays show temperature trends, valve feedback, heater command versus heater status, and permissives. Neutral colors represent normal conditions; abnormal states use standardized symbols, text, and colors.

The high-temperature alarm is rationalized with a defined consequence, response, priority, and response time. A transmitter-quality alarm is separated from the process-temperature alarm. The heater is interlocked by the PLC with an independent high-high temperature trip, while the operator alarm requests investigation and controlled response. Changeover-related messages are converted to state-based suppression only when the suppression rule is documented, authorized, and observable.

The historian stores temperature, level, heater status, recipe identifier, batch phase, alarm events, quality flags, and operator commands. Reports compare temperature profiles by batch phase rather than merely by clock time. Recipe downloads require authorization and verification.

Outcome

The redesigned screens reduce visual competition and make equipment feedback explicit. Alarm analysis becomes more meaningful because nuisance changeover alarms are reduced without hiding genuine hazards. Investigators can correlate a temperature excursion with recipe, phase, operator action, and instrument quality.

Learning points

• A display must support diagnosis, not just visibility.
• Alarm acknowledgement is not alarm correction.
• Automatic protection and operator alarms serve different functions.
• Historian values become more useful when linked to operating context.
• Improvements require lifecycle ownership, testing, training, and management of change.

7. Implementation, Verification, and Governance

HMI and alarm projects should use a structured workflow:

1. Document the operating philosophy and user requirements.
2. Create tag, equipment, alarm, and recipe standards.
3. Develop displays and alarm records from approved engineering data.
4. Conduct functional testing, including bad inputs, communication loss, stale data, and failover.
5. Perform operator-centered validation using realistic scenarios.
6. Train operators and maintenance personnel.
7. Monitor performance after commissioning.
8. Control revisions through management of change.

Testing should include normal operation, startup, shutdown, manual mode, emergency conditions, sensor failure, network interruption, server failure, and restoration from backup. Cybersecurity testing should be coordinated so that it does not compromise production or safety.

Ethically, designers have a duty to avoid misleading displays, hidden assumptions, and unjustified alarms. Audit trails and user permissions protect accountability, but they must not be used to assign blame without considering system design and operating conditions. Personal data in operator logs should be handled according to organizational policy and applicable law.

Artificial intelligence can assist with anomaly detection, alarm clustering, predictive maintenance, and natural-language search of historical data. However, AI recommendations require validated data, explainable reasoning appropriate to the risk, human oversight, and clear separation from safety-critical automatic action unless formally engineered and certified. An AI model should not silently change alarm limits or suppress alarms.

Chapter Summary

HMI, SCADA, historians, recipes, reports, and alarm systems form an integrated supervisory information layer. HMI design should follow a documented philosophy, use hierarchical displays, present abnormal conditions clearly, and support perception, diagnosis, decision, action, and verification. SCADA provides supervisory monitoring and command while PLCs retain deterministic control and interlocking functions.

Historians preserve time-series data together with quality, units, source, and operating context. Trends and reports are useful only when sampling, aggregation, data quality, and calculation rules are understood. Recipes require authorization, version control, limits, verification, and execution history.

Alarm management is a lifecycle discipline. Rationalized alarms identify a consequential abnormal condition, require operator action, and specify response, priority, limit, and time. Hysteresis, delays, state-based design, shelving controls, and performance metrics help reduce nuisance alarms and alarm floods. Effective systems are verified with realistic scenarios, secured through appropriate governance, and continuously improved.

Key Terms

HMI: Human–machine interface used for operator monitoring and interaction.

SCADA: Supervisory control and data acquisition system.

Historian: Time-series database for process, event, and contextual data.

Alarm: Indication of an abnormal condition requiring operator response.

Alarm rationalization: Structured review establishing an alarm’s need, priority, limit, consequence, and response.

Alarm flood: Condition in which alarm arrival exceeds effective operator processing capacity.

Alarm shelving: Authorized temporary suppression of an alarm.

Hysteresis: Difference between alarm activation and reset thresholds.

Deadband: Range within which a change may not generate a new stored value or alarm transition.

Standing alarm: Alarm that remains active for an extended period.

Chattering alarm: Alarm that repeatedly activates and clears in a short period.

Faceplate: Detailed HMI object for monitoring and controlling a device or loop.

Permissive: Condition that must be satisfied before an action is allowed.

Interlock: Logic that prevents or forces an action to protect equipment or process safety.

Recipe: Controlled set of product, material, sequence, and parameter instructions.

Quality flag: Metadata indicating whether a process value is good, uncertain, substituted, or unavailable.

Time synchronization: Alignment of clocks across automation and information systems.

Management of change: Formal process for evaluating and approving modifications.

Review Questions

Short Answer Questions

1. Distinguish an HMI from a historian.
2. Why should color not be the only means of communicating alarm status?
3. What information should an alarm record contain besides its tag name?
4. Define alarm shelving and identify one control required for its safe use.
5. Why is time synchronization important in event analysis?

Long Answer Questions

1. Explain a suitable HMI display hierarchy for a process plant and the purpose of each level.
2. Describe the alarm-management lifecycle from philosophy through continuous improvement.
3. Explain how historian metadata and operating context improve troubleshooting and reporting.
4. Discuss the design requirements for a secure and auditable recipe-management system.
5. Compare automatic interlocks with operator alarms and explain why both may be required.

Analytical / Application Questions

1. A plant receives 180 alarms in 3 hours, including 40 repeated alarms from one unstable transmitter. Calculate the average alarm rate and explain why the result alone is insufficient to judge alarm-system quality.
2. Design an HMI response for a pump start command that is issued successfully but receives no running feedback. Identify the displayed states, alarm or event behavior, and operator action.
3. For a high alarm with limit L = 80 °C and hysteresis h = 2 °C, state the activation and reset conditions. Explain how the choice of hysteresis affects nuisance alarms and response time.

Multiple Choice Questions with Answers

Question 1

Which system is primarily optimized for storing time-oriented process data?

A. PLC

B. Historian

C. Safety relay

D. Motor starter

Correct Answer: B. Historian

Question 2

What is the main purpose of an HMI display hierarchy?

A. To maximize the number of visible tags

B. To eliminate the need for alarms

C. To support navigation from overview to diagnosis and detail

D. To replace PLC interlocks

Correct Answer: C. To support navigation from overview to diagnosis and detail

Question 3

An alarm should generally be generated when a condition requires:

A. Operator response

B. Routine data archival only

C. A decorative screen change

D. Automatic database compression

Correct Answer: A. Operator response

Question 4

For a high alarm with limit L and hysteresis h, the alarm may clear when:

A. x ≥ L + h

B. x = 0

C. x ≤ L − h

D. x is unavailable

Correct Answer: C. x ≤ L − h

Question 5

If 120 alarm occurrences happen in 2 hours, the average alarm rate is:

A. 30 alarms/hour

B. 60 alarms/hour

C. 120 alarms/hour

D. 240 alarms/hour

Correct Answer: B. 60 alarms/hour

Question 6

Which statement about alarm acknowledgement is correct?

A. It proves the process is normal

B. It disables the alarm permanently

C. It means the operator has recognized the alarm

D. It replaces corrective action

Correct Answer: C. It means the operator has recognized the alarm

Question 7

Which feature is most important for a controlled recipe system?

A. Unrestricted editing by all users

B. Version control and authorization

C. Removal of execution history

D. Use of undocumented limits

Correct Answer: B. Version control and authorization

Question 8

Why should an HMI show command feedback separately from a command?

A. To distinguish requested action from actual equipment state

B. To increase animation

C. To avoid using PLC feedback

D. To hide communication failures

Correct Answer: A. To distinguish requested action from actual equipment state

Question 9

What is a principal risk of excessive alarm shelving?

A. Improved alarm visibility

B. Permanent hiding of important abnormal conditions

C. More accurate historian timestamps

D. Higher sensor accuracy

Correct Answer: B. Permanent hiding of important abnormal conditions

Question 10

Which information most improves interpretation of a historian temperature trend?

A. Screen background color

B. Recipe identifier and batch phase

C. Number of HMI buttons

D. Operator screen resolution

Correct Answer: B. Recipe identifier and batch phase