A companion alarm, sometimes called a consequential alarm, is an alarm whose activation is a known and predictable result of another alarm, not an independent event worth an operator's separate attention. When a pump trips, the low flow, low downstream pressure, and low level alarms that follow are all companions of the pump trip; they tell the operator nothing new, because they are exactly what a pump trip is expected to cause. The value of naming these relationships is that the alarm system can suppress the companions and present only the root alarm, so the operator sees the cause instead of a screen full of its consequences. This page is about how those defined cause and effect pairs are configured, how they reduce alarm flood, and how they differ from suppression that is not based on a specific known relationship.
Companion alarm in one line: A companion alarm is an alarm that is a known downstream consequence of another alarm, so its activation adds no new information once the causing alarm is already active. By defining the cause and effect relationship in advance, the alarm system can automatically suppress the companion whenever its parent alarm is present, leaving the operator with the root-cause alarm rather than a flood of follow-on alarms. This is different from generic flood suppression because it acts only on specifically identified cause-consequence pairs.
Every process has chains of events where one abnormal condition inevitably produces others, and the alarms on those downstream conditions are companion alarms. If a feed pump trips, the flow it was providing collapses, so a low flow alarm activates; the vessel it fed stops being replenished, so a low level alarm follows; the header it pressurized sags, so a low pressure alarm follows too. None of those three alarms is wrong, and each would be meaningful on its own if it appeared in isolation. But once the operator knows the pump has tripped, they already know all three will happen, so annunciating them as separate alarms does not help the operator understand or respond; it just repeats the single fact that the pump is down in three noisier ways.
The defining feature of a companion alarm is this predictability of the relationship. A companion is not merely an alarm that happens to occur at the same time as another; it is one that is a direct, understood consequence of the other, such that an engineer reviewing the process can say with confidence that whenever the parent alarm is true, this alarm is expected to follow. That confidence is what makes it safe to suppress. You are not hiding an independent problem; you are declining to repeat a consequence the operator can already infer from the cause. The root alarm, the pump trip, is left fully visible and unsuppressed, so nothing about the actual problem is concealed.
This framing also clarifies what is not a companion alarm. Two alarms that tend to occur together for a shared external reason, such as several instruments in the same area reading badly during a power dip, are not in a cause-consequence relationship with each other; neither one causes the other. And an alarm that could indicate a new, independent fault, even one that often accompanies another alarm, is not a good candidate for companion suppression, because suppressing it might hide a genuinely separate problem. The companion relationship has to be a real causal dependency, verified during design, not just a statistical tendency to appear at the same time.
Configuring a companion alarm means declaring a dependency: this alarm is a companion of that alarm, so suppress this one whenever that one is active. The parent alarm is the cause, the companion is the effect, and the rule is a conditional suppression tied to the parent's state. When the parent is not active, the companion behaves as a normal alarm and annunciates on its own, because on its own it does mean something. When the parent is active, the companion is suppressed, held out of the operator's alarm list because its information is redundant given the parent. As soon as the parent clears, the companion goes back to normal behavior, ready to annunciate independently again if the condition persists for some other reason.
Building these dependencies is a design activity done during alarm rationalization, not something an operator sets up in the moment, because it requires knowing the process well enough to be certain of the causal chain. The engineer identifies a causing event, enumerates the alarms it reliably produces, and links each of those as a companion of the cause. Getting the direction right matters: the pump trip is the parent and the low flow is the companion, never the reverse, because low flow does not cause a pump trip. Getting the confidence right matters too, because a link asserted on a weak relationship risks suppressing an alarm that could sometimes carry real independent meaning, so borderline cases are usually left unsuppressed.
A subtlety worth handling carefully is what happens when a companion could itself be caused by more than one thing. Low downstream pressure might be a companion of a pump trip, but it might also arise from a leak that has nothing to do with the pump. If the suppression rule only fires the companion out of the list when the pump-trip parent is active, then a low-pressure event caused by a leak, with no pump trip present, still annunciates normally, which is the desired behavior. The dependency is conditional on the specific parent, so companion suppression narrows what it hides to exactly the case where the parent explains the effect, and leaves the effect visible in every other case.
The reason companion alarms matter so much is alarm flood. A single significant upset can set off a cascade of alarms in a short window, and the operator most needs clarity at exactly the moment the screen fills with the most alarms. Many of those cascade alarms are companions of a single root cause, so defining the cause-consequence relationships and suppressing the companions can dramatically thin the list the operator has to read during the upset. Instead of a scroll of a dozen low-flow, low-level, and low-pressure alarms, the operator sees the pump trip, which is the one fact that explains all of them and points directly at the action to take.
This is different from generic flood suppression, which reacts to the rate or count of alarms rather than to specific known relationships. Rate-based flood handling might suppress or group alarms simply because too many arrived too fast, without any model of which alarm caused which. Companion suppression is more surgical and more trustworthy precisely because it is based on defined pairs: it always suppresses the same known consequence of the same known cause, so its behavior is predictable and reviewable, and it never hides an alarm that has not been specifically judged to be a redundant consequence. Both approaches reduce flood, but companion suppression does it with a documented causal justification for each hidden alarm.
In a cloud SCADA setting the payoff is even sharper, because alarms are often delivered as push notifications to operators who are not sitting in front of a board. When a remote station has an upset, a naive system might fire off a burst of a dozen notifications to an on-call operator's phone, most of them companions of a single root fault, which is both alarming and useless. Defining the companion relationships so that only the root alarm generates a notification means the operator receives the one message that actually explains the situation, rather than a cascade to dig through. A platform such as Merobix, which evaluates related alarms across a site's tags and can hold companions when their parent is active, turns a flood of consequential notifications into a single actionable one pointed at the true cause.
Companion suppression acts on specifically defined cause-consequence pairs, always hiding the same known consequence of the same known cause, so each suppression has a documented justification. Generic flood suppression reacts to the rate or number of alarms arriving, without a model of which alarm caused which. Both reduce flood, but companion suppression is more surgical and reviewable because it only ever hides alarms that were judged in advance to be redundant consequences of an active parent.
No, when it is configured correctly. A companion is only suppressed while its specific parent alarm is active, and the parent, the root cause, stays fully visible. If the same downstream condition occurs for a different reason, with no parent alarm present, the companion annunciates normally. So the operator still sees every genuinely independent problem and simply avoids seeing the same consequence repeated when its cause is already on the screen.
Engineers define them during alarm rationalization, not operators in the moment, because a companion link requires confident knowledge of the causal chain in the process. The engineer identifies a causing event, lists the alarms it reliably produces, and links each as a companion of the cause with the direction and conditions set correctly. Weak or uncertain relationships are usually left unlinked so that no alarm carrying possible independent meaning is suppressed.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.