Every alarm owned. Every site visible.

Each alarm event page carries an Acknowledge action that records who accepted the alarm and when, creating a time-stamped record rather than a checkbox. Acknowledgement appears only while the event is still active and only on alarms that have Enable Acknowledgement switched on; a cleared event cannot be acknowledged after the fact, which keeps the record honest about whether anyone responded while it mattered. Assignment is tracked separately, so the team can distinguish who is working an event from who has formally accepted it, and the rest of the shift filters by assignment to see what is already covered. The Alarms page keeps score across both: one summary card counts events still awaiting acknowledgement and another counts events with nobody assigned, so gaps in coverage are numbers on a screen instead of a surprise at handover.

Yes, through alarm groups, and the routing takes three steps that all have to line up: the alarm belongs to a group, the group enables the channels it uses, and each person subscribes per channel on the group's subscriptions page. SMS, email, and push are switched on independently per group, and a channel the group has disabled cannot be subscribed to at all. That makes it practical to organize alarms by response rather than by equipment: a Critical Power group that pages the on-call engineer by SMS, and a Mechanical Systems group that only sends email, is easier to keep honest than one group per panel. An alarm left with no group still records its events and appears on the Alarms page, but sends nothing, which suits conditions worth logging that nobody should be woken up for.

With a processing delay set per alarm: no delay, 30 seconds, 1 minute, 5 minutes, or 15 minutes. When a reading first crosses the threshold, the alarm waits out the chosen interval and then re-reads the current value; if it has settled back, nothing is recorded or sent, and the next crossing starts a fresh window. A sustained fault still fires exactly one delay interval after the first crossing, however many readings arrive in between, so filtering spikes never silences a real condition. Two other guards matter in practice: the create dialog refuses a second alarm with an identical condition on the same variable, so duplicate rules cannot notify twice for one reading, and severity levels from Info to Critical keep low-stakes alarms out of the filters and summary cards the shift actually watches.

The ControlCom Edge Server runs on hardware at the site and does not need the cloud to do its local job. Alarms enabled for the Edge Server are checked on the gateway itself during the outage, and their events are distributed to any Edge HMIs connected to it, so screens at the site keep showing live state and active alarms. Readings are buffered locally and sent when the link returns, so alarm history and trends carry no gap for the outage, which matters when the post-incident review reconstructs the timeline. What an outage does interrupt is remote notification, since a message cannot leave a site with no connectivity. That is the argument for putting the alarms that protect equipment on the gateway itself, where they keep evaluating with or without the WAN.

Yes. Alarm History records every event for the whole organization and opens on the current year to date, with a calendar view that shows occurrences per day so a bad week is visible at a glance. The Alarm Breakdown panel compares this week, month, and year against the preceding period and ranks the top alarm groups and locations for the range, and clicking a bar filters the table to that group or location, the fastest route from "we had a bad month" to the equipment responsible. Filters cover severity, state, asset, location, group, assignment, and date range, and every filter is mirrored into the page URL, so a filtered view can be sent to a colleague as a link. Export All fetches the full filtered result set to CSV, and each alarm's own event history lists every trigger and recovery with the reported value and how long the condition lasted.

No. The ControlCom Edge Server reads from existing controllers, BMS, and SCADA over Modbus TCP/RTU, OPC-UA, BACnet, EtherNet/IP, and MQTT, and the control layer keeps doing exactly what it does today. What changes is where the operations work happens: instead of alarm state living on one console in one control room, every site's alarms land in one list with severity, assignment, and acknowledgement tracked, notifications reach phones rather than consoles, and the history of every event is searchable across the whole estate. The rollout reflects that division: no control logic is modified and no downtime is scheduled, because the work is configuring protocol clients, alarm groups, and subscriptions rather than reprogramming anything, and the first sites are typically reporting within days of the Edge Server container starting. If the control system is ever upgraded or swapped later, the monitoring layer stays where it is, because it depends on the protocols rather than on any one vendor's head end.

Because the summary stops at the control room wall, and most of what goes wrong happens when nobody is standing in front of it. A SCADA alarm list shows one site to whoever is present; it does not page the person on call by SMS, record who acknowledged what and when, carry the night shift's notes forward to the next crew, or put a dozen sites' alarms into one ranked history. Those are the gaps ControlCom Connect fills, and it fills them by reading the same points SCADA already exposes, typically through the OPC UA client, so nothing about the control system changes. The control room keeps its summary for the operators in the seat. The platform covers everyone else: the on-call engineer at home, the supervisor doing Monday's review, and the incoming shift inheriting an open event with its context attached.