From Sensors to Actionable ProSight Alarms: Thresholds, Delays, Deadbands, and Escalation

A remote sensor can report a value every few seconds and still fail to help anyone make a good decision. The useful work starts when that raw signal becomes a clear ProSight alarm, with the right priority, the right timing, the right owner, and a known path for response.

Data on its own is quiet. It may show a tank level rising, a pump drawing more current than usual, or a room temperature drifting out of range. Unless the system can turn that change into a meaningful alarm, the people responsible for the asset are left sorting through noise.

That is where good alarm management earns its place. A well-designed alarm does more than announce that something changed. It tells the right person that something needs attention, gives enough context to act, and avoids distracting the team when no action is needed.

Remote sensors are the start of the alarm journey, not the end.

Remote sensors start the journey, but decisions finish it

Remote sensors are the eyes and ears of a monitoring system. They measure conditions such as:

• Tank level

• Flow rate

• Pressure

• Temperature

• Vibration

• Power status

• Battery voltage

• Door or hatch position

• Pump run state

  
  

These values may arrive from many kinds of assets, including utilities, mines, treatment plants, farms, remote depots, environmental stations, and industrial sites. ProSight can use this information to raise alarms, but the quality of those alarms depends on the thinking behind them.

A raw data point might say:

`Tank Level = 92%`

That is useful, but incomplete. Is 92% safe? Is it expected during the morning fill cycle? Has the level been high for ten seconds or ten minutes? Who should know? What should they do?

A strong alarm definition answers those questions before an event occurs. It sets the measurement point, the alarm condition, the delay, the reset behaviour, the owner, and the escalation path.

Without that design, a monitoring system can create two common problems.

The first is alarm noise, where small or harmless changes trigger too many notifications. People begin to ignore them.

The second is alarm silence, where a serious condition is visible in the data but never becomes an alarm that reaches the right person.

Both problems weaken trust in the system. Good alarm management sits between those extremes.

Thresholds define when a condition matters

A threshold is the value that separates normal operation from a condition that needs attention. It is one of the simplest alarm concepts, and one of the easiest to get wrong.

For example, a water storage tank might have a high-level alarm at 90%. When the sensor reads above 90%, ProSight can raise an alarm.

That sounds simple, but the right threshold depends on the asset and the consequence.

A tank at 90% may be fine if overflow protection starts at 98% and the inflow rate is low. The same 90% may be urgent if the tank fills quickly and sits near a sensitive area.

Good thresholds reflect operating reality. They should consider:

• Normal operating range

• Safe operating limits

• Rate of change

• Site conditions

• Seasonal patterns

• Consequences of missing the event

• How long the team needs to respond

  
  

A temperature alarm gives a clear example. Suppose a cold storage room must stay below 5°C. Setting a high-temperature alarm at 5.1°C may cause constant nuisance alarms every time the door opens. Setting it at 10°C may catch the issue too late.

A better approach could be:

Measured condition	Alarm meaning	Example response
Above 5°C for a short time	Watch condition	Check whether door activity explains it
Above 7°C for several minutes	Warning alarm	Inspect cooling unit or door seal
Above 10°C	Critical alarm	Attend site or move stock if needed

This kind of tiering helps the alarm match the level of risk. Not every abnormal value deserves the same response.

Thresholds also need review. Assets age, operations change, and seasonal conditions shift. A threshold that made sense during commissioning may become too tight, too loose, or irrelevant a year later.

A useful threshold is not just a number. It is a decision point that should lead to a known action.

Delays stop short-lived events from becoming false alarms

A delay is the time a condition must remain true before ProSight raises the alarm. Delays protect the team from short spikes, sensor jitter, and harmless transients.

Take a pressure sensor on a pipeline. The pressure may drop for a few seconds when a pump starts, a valve opens, or demand changes. If every brief dip triggers an alarm, operators soon lose confidence in the alert.

A delay solves this by asking a simple question:

Has the condition persisted long enough to matter?

For example:

• Low pressure threshold

Below 250 kPa

• Alarm delay

120 seconds

• Alarm result

ProSight raises the alarm only if pressure stays below 250 kPa for two minutes

This small rule can remove a large amount of noise. The key is choosing a delay that filters harmless events without hiding real ones.

A door alarm shows the same principle. A remote equipment cabinet may have a door-open sensor. If a technician opens the door during a planned visit, the system does not need to wake the on-call team after five seconds. A five-minute delay may make more sense.

By contrast, some alarms should have little or no delay. A fire signal, high-high pressure event, or emergency stop activation may need immediate notification. The delay should match the risk.

Small signal changes need smart timing before they become alarms.

Good alarm delays often balance three questions:

• How fast can the condition become unsafe?

• How often does the signal fluctuate during normal operation?

• How long does the response team need to act?

  
  

If a delay feels like a workaround for a noisy sensor, check the sensor as well. A bad installation, poor calibration, loose wiring, or unsuitable measurement range can all create poor data. Software rules can help, but they should not hide faulty instruments.

Deadbands prevent alarms from chattering

A deadband is the gap between the point where an alarm activates and the point where it clears. It prevents a value hovering near the threshold from switching the alarm on and off repeatedly.

This repeated switching is often called chattering. It is frustrating, and it can fill an alarm history with events that are technically true but operationally useless.

Imagine a generator cooling system with a high-temperature alarm at 85°C. If the temperature moves between 84.9°C and 85.1°C, the alarm may activate, clear, activate again, and clear again within minutes.

A deadband fixes that behaviour. The alarm might activate at 85°C but only clear when the temperature falls below 82°C.

That gives the process room to recover before the system declares the alarm resolved.

Here is a simple example:

Alarm setting	Value
Alarm activates	Temperature above 85°C
Alarm clears	Temperature below 82°C
Deadband	3°C

Deadbands are especially useful for analogue signals such as level, pressure, temperature, flow, and vibration. These values often move in small steps, even when nothing important has changed.

A tank level example makes the benefit clear. Suppose a high-level alarm activates at 90%. Without a deadband, waves, inflow pulses, or sensor movement could cause rapid alarm changes around 90%. With a clear point at 87%, the alarm remains active until the tank has genuinely returned to a safer level.

Deadbands should not be so wide that they hide a continuing issue. If the alarm clears too late, people may think the system is slow or inaccurate. If it clears too early, chattering returns. The right setting depends on how the process behaves.

A useful question is:

What value shows the condition has truly returned to normal?

The answer becomes the alarm reset point.

Good alarms need context, not just conditions

Thresholds, delays, and deadbands decide when ProSight alarms activate and clear. Context decides whether those alarms are useful once they arrive.

An alarm message that says `Level High` may be correct, but it does not say enough.

A more useful alarm message might include:

• Asset name

• Measured value

• Alarm limit

• Time active

• Site location or area

• Suggested first check

• Priority level

• Contact or role responsible

  
  

For example:

`North Bore Tank high level. Current level 93%. Alarm limit 90%. Active for 10 minutes. Check inlet valve and transfer pump status.`

That message gives the responder a head start. It reduces guessing and helps newer team members follow the expected first step.

Context also helps separate symptoms from causes. A low tank level alarm may be caused by a failed pump, a closed valve, a high-demand period, or a sensor fault. The alarm does not need to solve the whole problem, but it should help the responder choose the first useful action.

Good alarm wording is specific, plain, and consistent. Avoid vague labels such as `Fault`, `Problem`, or `Alert` when a more exact description exists.

Alarm ownership prevents confusion during response

Every alarm should have an owner. Ownership answers one practical question:

Who is responsible for making sure this alarm is addressed?

This does not always mean the owner personally attends the site. The owner may assess the event, contact a field technician, check related data, or confirm that another team has taken over.

Without ownership, alarms fall into gaps. One person assumes operations will handle it. Operations assumes maintenance has it. Maintenance assumes the duty technician has already been called. Time passes, and the alarm remains unresolved.

Ownership works best when it is assigned by role, not by a single person’s name. People change rosters, go on leave, and move between teams. Roles are easier to maintain.

Examples include:

• Duty operator

• On-call electrician

• Water network supervisor

• Maintenance coordinator

• Environmental compliance lead

• Site security contact

  
  

Ownership should also match the type of alarm. A low battery alarm on a remote telemetry unit may belong to maintenance. A high turbidity alarm may belong to operations or compliance. A forced entry alarm may belong to security.

Clear ownership starts with knowing which asset and condition need attention.

Clear ownership needs supporting rules:

• Each alarm class has a default role owner

• Rosters stay current

• Handover covers active alarms

• Owners can acknowledge alarms without closing them too early

• Closed alarms include a reason or resolution note when needed

  
  

Acknowledgement is not the same as resolution. Acknowledging an alarm means someone has seen it and taken responsibility. The alarm should remain visible until the condition clears or a controlled decision is made.

This distinction matters. If acknowledgement hides an alarm, the risk can disappear from view while the problem continues.

Escalation turns missed alarms into managed risk

Even with clear ownership, alarms can be missed. Phones fail. People are already handling another incident. A notification arrives during poor reception. The roster may have an error.

Escalation processes reduce the chance that one missed step becomes a serious failure.

An escalation path defines what happens when an alarm is not acknowledged or resolved within a set time. It may move from one person to another, from one role to another, or from a normal channel to a more urgent one.

A basic escalation process might look like this:

Time after alarm	Action
0 minutes	Notify duty operator
10 minutes	If unacknowledged, notify on-call technician
20 minutes	If still unacknowledged, notify supervisor
30 minutes	If critical and unresolved, follow incident procedure

The right timing depends on the alarm. A low-priority maintenance alarm may escalate after hours or days. A critical overflow risk may escalate within minutes.

Escalation also needs to respect alarm priority. If every alarm escalates quickly to senior staff, the process becomes noise. If serious alarms do not escalate fast enough, the organisation carries hidden risk.

A strong escalation process defines:

• Which alarms escalate

• How long each step waits

• Who receives each level

• What acknowledgement means

• What happens after hours

• What happens if communications fail

• When an incident process begins

  
  

Escalation is not a substitute for good first response. It is a safety net. The goal is to make sure important alarms keep moving until someone takes responsibility.

Building ProSight alarms that people trust

Trust is the real measure of alarm quality. If people trust the alarms, they respond quickly. If they do not, they create workarounds, mute notifications, or wait for other confirmation.

Trust grows when alarms are accurate, useful, and consistent.

A practical alarm design process can follow this path:

1. Start with the asset and consequence

   Identify what can go wrong and why it matters. A pump failure, tank overflow, high temperature, or low battery each has a different consequence.

   
   

1. Choose the signal that best represents the condition

   Use the sensor that gives the clearest indication. A pump running signal may not prove flow. A flow meter or pressure change may tell the real story.

   
   

2. Set a meaningful threshold

   Choose a value that reflects risk, not just convenience. Use historical data where available.

   
   

1. Add a delay where short events do not matter

   Filter brief changes while protecting rapid-response alarms.

   
   

2. Apply a deadband for analogue values

   Stop chattering and make alarm clearing more reliable.

   
   

1. Write a clear alarm message

   Include the asset, value, limit, and likely first action.

   
   

2. Assign an owner

   Make one role responsible for response and follow-up.

   
   

1. Define escalation

   Decide what happens when the alarm is not acknowledged or resolved.

   
   

2. Review alarm history

   Look for repeated alarms, nuisance alarms, stale alarms, and missed events.

   
   

10. Improve the rules over time

Alarm management is not a one-off setup task. It improves as the team learns how the asset behaves.

The review step is often where the best improvements appear. If one alarm triggers every day but rarely requires action, it needs attention. The threshold may be wrong. The delay may be too short. The equipment may need maintenance. The message may be unclear.

If a serious event occurred but no alarm reached the right person, the design needs correction. The data may have been available, but the system did not turn it into a useful call to act.

Alarm response depends on clear rules before anyone reaches the site.

The goal is action, not more alarms

More alarms do not mean better monitoring. More data does not guarantee better control. The goal is to create alarms that point to real conditions, reach the right owner, and lead to a timely response.

Thresholds decide when a value matters. Delays confirm that the condition has lasted long enough to act on. Deadbands keep alarm behaviour stable. Ownership makes responsibility clear. Escalation keeps important issues from being forgotten.

Together, these rules turn remote sensor data into ProSight alarms that people can trust.

A good test is simple. When an alarm arrives, can the responder answer these questions quickly?

• What happened?

• Where did it happen?

• How serious is it?

• What should I check first?

• Am I responsible?

• Who is next if I cannot respond?

  
  

If the answer is yes, the alarm is doing its job. If not, the system may be collecting data without turning it into action. That gap is where effective alarm management makes the difference.