Machine Design #39: Maintenance Alarms — Do Not Stop at “Error”

“Cylinder error.” “Sensor abnormal.” “Machine fault.” These messages tell the operator that production has stopped, but they do not explain what happened, where it happened, what evidence the controller saw, or what action is permitted.

A useful alarm is part of the machine's diagnostic architecture. It preserves the initiating event, captures relevant context, guides the correct role toward a legitimate response, and provides data for improving the machine. The goal is not to display more red text. The goal is to reduce unsafe guessing and shorten the path from symptom to verified cause.

This article presents a practical design framework. It does not replace a machine risk assessment, safety-system indication requirements, company alarm philosophy, cybersecurity controls, or validation of the actual machine and process.

1. First: not every message is an alarm

A healthy HMI distinguishes several message classes.

Message class	Purpose	Typical response
Status	Describes the current operating state	Observe; no intervention required
Prompt	Requests a defined operator action	Load, unload, confirm, or select
Warning	Indicates degradation or an approaching limit	Plan inspection or maintenance
Process inhibit	Explains why a start or transition is not permitted	Restore a missing operating condition
Alarm	Reports an abnormal condition requiring timely response	Stabilize, diagnose, correct, and recover
Safety indication	Shows the state of a safety function or device	Follow the validated safety and reset procedure

If every message is red, flashing, and audible, the display stops communicating priority. If normal prompts are logged as faults, alarm history becomes too noisy to support root-cause analysis.

2. Why “Cylinder error” is a weak alarm

The message leaves essential questions unanswered:

Which cylinder and station?
Which requested movement failed?
What command was issued?
Which end sensor was expected?
What were the actual sensor states?
How long had the movement been running?
Was pressure adequate?
Is the workpiece or another mechanism blocking travel?
May the operator retry, or is maintenance intervention required?

A weak alarm forces people to open the electrical drawing, search PLC tags, or repeatedly reset the machine. Repeated resetting can erase evidence, move a jammed mechanism, or transform a recoverable fault into equipment damage.

3. Structure an actionable message

A practical alarm contains five elements:

Object and location: Station 20, lift cylinder CY-204.
Requested action: Failed to reach raised position.
Observed evidence: Raised sensor OFF after 1.8 s; lowered sensor OFF; pressure 0.42 MPa.
Likely checks: Inspect obstruction, air supply, sensor target, and valve output.
Allowed next action: Use recovery mode after the area is clear; call maintenance if the state remains unknown.

Example:

S20 / CY-204 lift did not reach UP position within 1.8 s. UP sensor is OFF, DOWN sensor is OFF, manifold pressure is 0.42 MPa. Check for mechanical obstruction and air pressure. Do not force the output. After confirming the zone is clear, use Recovery → Lift inspection.

The HMI need not show every engineering detail in the headline. Use a short primary message with expandable evidence and procedure. The first screen should still answer where, what, and what legitimate action comes next.

4. Capture context at the instant the fault occurs

Live values change after a fault. Pressure may recover, an actuator may drift, an operator may move a part, a network may reconnect, and sequence logic may clear intermediate bits. If the HMI only displays current values, the evidence from the initiating moment disappears.

Store a context snapshot when the alarm first becomes active:

Timestamp with sufficient resolution.
Machine mode, state, step, recipe, and part identifier.
Active command and elapsed action time.
Relevant input and output states.
Axis position, speed, torque, or following error.
Pressure, vacuum, flow, force, temperature, or process result.
Communication and device-health status.
Safety-zone state where relevant and appropriate for access control.

Choose the smallest useful context set for each alarm family. Logging the entire PLC memory creates volume without meaning and may expose information that should be access-controlled.

5. Preserve first-out so consequences do not hide the cause

One initiating fault can create dozens of secondary alarms. A pressure loss may cause several cylinders to time out, a robot handshake to fail, a workpiece check to disappear, and downstream stations to become not ready. If the HMI sorts only by latest or highest count, the original pressure event can vanish under its consequences.

First-out logic records the first relevant event in a fault episode and freezes its context. Subsequent alarms remain visible but are linked as consequences or concurrent events. Define episode boundaries: when it begins, when it is considered stable, and when first-out may be cleared.

First-out is not necessarily the root cause. It is the earliest observed evidence under the selected scope and scan resolution. Treat it as a strong diagnostic lead, then confirm the physical cause.

6. Distinguish acknowledge, condition clear, and reset

These actions have different meanings.

Acknowledge: a person confirms that the message has been noticed. It does not repair the fault.
Condition clear: the physical or logical condition that generated the alarm is no longer present.
Reset: the control system accepts a deliberate command to restore eligibility for a defined operation after required checks.

Do not clear an active condition merely because somebody acknowledged it. Do not let reset erase history before the context is stored. Do not automatically restart motion when a condition clears.

The HMI should show each state clearly: active-unacknowledged, active-acknowledged, cleared-unacknowledged where needed, and historical. Safety-function reset remains subject to its own validated rules and must not be mixed casually with a general process alarm reset.

7. Priority must follow the required response

Priority is not a measure of how annoying a fault is or which department requested the alarm. It should reflect the urgency and consequence of the required human response.

A useful priority model asks:

Is immediate action required to protect people, equipment, product, or environment?
How quickly must the action occur?
What happens if nobody responds?
Is the response available to the operator, or does it require maintenance or engineering?

Use a small number of priority levels with explicit criteria. Reserve audible and flashing indication for conditions that truly need timely attention. If 80 percent of alarms are “High,” the priority system provides no guidance.

Priority may differ from severity. A severe event that is already safely contained may require investigation but no immediate operator action. A less severe process deviation may need a rapid response to prevent a large batch of defects.

8. Design by ownership: who will respond?

Operator

Operator messages should identify the location and permit safe, routine actions: load the correct part, close a guard, replenish material, inspect an accessible obstruction, or select a defined recovery step. Do not ask operators to force PLC bits, adjust undocumented sensors, or enter a hazardous area without the required procedure.

Maintenance

Maintenance information should include component tag, drawing reference, actual and expected signals, first-out context, relevant trends, likely mechanical/electrical/fluid checks, isolation requirements, and proof test after repair.

Engineering

Engineering needs richer evidence: software and recipe revision, state transitions, event correlation, cycle distribution, device codes, parameter changes, and recurrence patterns. This data supports root-cause analysis and design changes.

One alarm can present layered information for all three roles. Keep the operator headline concise, then provide authorized detail without exposing dangerous bypass instructions.

9. Tie timeout to physics, not just a number

A cylinder timeout should reflect stroke, flow, load, cushioning, supply pressure, temperature, PLC scan, network update, sensor response, and validated margin. Selecting five seconds because “it seems long enough” creates either nuisance stops or slow fault detection.

Record normal action-time distribution across credible conditions. Set warning and alarm thresholds with engineering justification. Trend the actual duration; a cylinder that drifts from 0.7 to 1.4 seconds may reveal leakage, friction, contamination, or pressure loss before reaching a 2-second timeout.

Separate failure modes where useful: never left the initial sensor, both end sensors active, target state not reached, movement too slow, pressure not established, or sensor transition implausible. Each points to different checks.

10. Do not only store alarms; learn from history

Alarm history should support questions that lead to action:

Which alarms create the most downtime, not merely the most occurrences?
Which event is most often first-out?
Which station, model, shift, or operating phase is associated with it?
How long does acknowledgement, diagnosis, repair, and recovery take?
Which alarms repeatedly clear after reset without a recorded correction?
Which warnings predict a later stop?
Which alarms are standing, chattering, duplicated, or never used?

Review alarm performance periodically. Remove duplicates, correct unclear text, adjust justified limits, improve sensors and context, and convert recurring evidence into design action. Never suppress an alarm only to improve a dashboard metric; resolve the underlying nuisance or classification problem.

Maintain alarm definitions under revision control. Changes to priority, condition, delay, text, reset behavior, or response procedure can alter machine behavior and require testing.

11. Checklist for designing one mechanism's alarms

Purpose and classification

[ ] The message is correctly classified as status, prompt, warning, process inhibit, alarm, or safety indication.
[ ] The abnormal condition and required response are explicit.
[ ] Priority follows documented response criteria.

Trigger and evidence

[ ] The trigger is based on a physical model and known signal behavior.
[ ] Timeout comes from measured or calculated motion and system latency.
[ ] Transition and plausibility faults are distinguished where useful.
[ ] First-out and relevant context are captured before values change.

Message

[ ] Object, station, and requested action are named.
[ ] Actual and expected evidence is available.
[ ] Guidance describes legitimate checks, not bypass.
[ ] Translation uses plant terminology consistently.

Lifecycle

[ ] Acknowledge, condition clear, reset, and restart are separate.
[ ] Role ownership and escalation are defined.
[ ] History supports downtime and recurrence analysis.
[ ] Definition, text, limits, and procedures are revision-controlled.

Safety and access

[ ] Alarm guidance respects guarding and energy-isolation requirements.
[ ] Safety indications follow validated reset/restart behavior.
[ ] Detailed diagnostic data and remote access have appropriate authorization.

12. Accept the machine with controlled fault scenarios

Normal production runs prove that the happy path works. Alarm acceptance requires deliberate, controlled faults with appropriate safety precautions.

Test cases can include:

Disconnect or misalign a non-safety process sensor.
Block an actuator under a controlled and assessed condition.
Reduce utility pressure to defined boundary values.
Interrupt device or station communication.
Present contradictory end-position signals.
Hold a handshake bit stale.
Trigger the same initiating fault at different sequence phases.
Generate several consequential alarms from one first-out event.
Restore the condition without acknowledging, then acknowledge without resetting.
Reboot or restore energy and verify no unexpected restart.

For each case, verify trigger time, message text, priority, first-out, snapshot, operator guidance, acknowledge/clear/reset behavior, history, and recovery path. Record expected and actual results for FAT and SAT.

Do not inject a fault in a way that bypasses the risk assessment or exposes personnel. Fault-injection methods themselves need planning and authorization.

Conclusion

An alarm should not merely announce that the machine has stopped. It should preserve evidence, show the affected object and requested action, guide the correct role, and support safe recovery.

Write messages that answer where, what, what was observed, and what legitimate action follows. Capture context at the initiating moment, preserve first-out, separate acknowledge from clear and reset, and set priority from required response.

The best alarm system reduces guessing. It helps operators recover correctly, gives maintenance a shorter diagnostic path, and turns recurring failures into engineering evidence for improving the next machine revision.

References

View all MINATA technical articles