How to Set Up Alarm Management of Change
Without a change process, a rationalized alarm system decays one quiet setpoint nudge at a time. This page is the procedure for standing up management of change for alarms: defining what triggers it, who approves, and how the change reaches the plant and the database together. For the concept, see what alarm management of change is; this is how you put the workflow in place.
Set Up Alarm Change Control in one line: To set up alarm management of change, define which alarm attributes require a change request, build a workflow where each change is requested with a reason, reviewed against the philosophy, and approved by a competent authority, then implement the change in both the controller and the master alarm database and record it in an auditable log.
Define What Triggers a Change Request
Decide precisely which alarm attributes cannot be altered without a change request: setpoint, priority, deadband, on-delay and off-delay, and enabled or suppressed state at a minimum. Anything on that list changed on the console without a request is a violation, so the list has to be explicit and known to everyone who can touch the configuration.
Include creating and deleting alarms in the trigger list, not just editing existing ones, because a new alarm added outside the process is as much a drift as a modified one. The scope of the trigger defines the scope of the control.
Build the Request-Review-Approve Workflow
Construct the workflow so every change starts as a request stating the reason and the specific attribute change. Route it to a competent reviewer who checks it against the alarm philosophy, particularly that a changed setpoint still clears normal operation and a changed priority still derives correctly from consequence and response time. Then require approval by the designated authority before anything reaches the plant.
Keep the workflow proportionate so it is actually used. A process so heavy that operators bypass it in an upset is worse than a lighter one they follow; where urgent changes are genuinely needed, define a controlled expedited path with after-the-fact review rather than an informal bypass.
Implement in Plant and Database Together
When a change is approved, implement it in the controller and in the master alarm database as one transaction, not two. The database must never lag the plant, because the moment it does, the next audit finds an undocumented change and the master stops being authoritative. Tie the two updates to the same approved request.
Update any dependent artifacts the change touches, such as the alarm response procedure if the corrective action changed. A change process that updates the setpoint but not the operator guidance leaves the console showing advice that no longer matches the alarm.
Record an Auditable Trail
Every completed change leaves a record: what changed, from what to what, why, who approved it, and when. This trail is exactly what an alarm system audit reconciles against, so it has to be complete enough that a later reviewer can trace any current setting back to the request that produced it.
Retain the trail so the history survives personnel and system changes. A change process whose records are overwritten or lost cannot support an audit, and the whole point of management of change is that every change can be accounted for after the fact.
Verifying the Workflow
Test the workflow with a real change end to end: raise a request, run it through review and approval, implement it in both the controller and the database, and confirm the trail captured everything. If any step can be skipped, or the database can be updated without an approved request, the control has a hole.
Audit a sample of recent live changes against the change log soon after go-live. If any plant change has no matching approved request, either the workflow is being bypassed or the trigger list is incomplete, and you fix the process before drift accumulates.
Common Mistakes to Avoid
The most common failure is a change process so cumbersome that operators route around it during upsets, so the very changes most worth recording are the ones that escape it. The fix is a proportionate workflow with a controlled expedited path, not an informal bypass.
Teams also update the controller without updating the database, reintroducing the drift the process exists to prevent. And they define the trigger list too narrowly, leaving alarm creation or deletion uncontrolled, so new undocumented alarms accumulate outside the very process meant to govern them.
Frequently Asked Questions
Which alarm changes actually need to go through management of change?
At minimum any change to a setpoint, priority, deadband, on-delay or off-delay, or enabled and suppressed state, plus the creation or deletion of an alarm, because each of those alters the alarm system's behavior and can degrade it if unreviewed. The guiding principle is that anything which changes what the operator sees or when they see it belongs under control; trivial cosmetic edits may not, but the trigger list should be explicit so there is no ambiguity about what requires a request.
How do you handle an urgent alarm change during an upset?
With a controlled expedited path, not an informal bypass. A change process that offers no legitimate fast route during upsets guarantees operators will route around it exactly when the change most needs recording, so define an expedited path that allows the urgent change with a lightweight approval and requires full documentation and review immediately afterward. That keeps genuinely urgent changes possible while ensuring they still end up in the auditable trail rather than becoming undocumented drift.
Automation services
Need help turning this into a working system?
Merobix integrates SCADA, programs Allen-Bradley and Siemens PLCs, and designs and fabricates industrial control panels.
Meeting requests are reviewed before confirmation.