Check out our White Paper Series!
A complete library of helpful advice and survival guides for every aspect of system monitoring and control.
1-800-693-0351
Have a specific question? Ask our team of expert engineers and get a specific answer!
Sign up for the next DPS Factory Training!
Whether you're new to our equipment or you've used it for years, DPS factory training is the best way to get more from your monitoring.
Reserve Your Seat Today
A campus served by more than one utility feed does not lose power all at once. It loses a section. Half the residence halls go dark while the academic buildings stay lit, and the people who have to decide whether to hold classes, where to send students, and which generators to check are working from phone calls and guesswork.
This article explains how to get real-time, building-level power status across a campus, why the reporting path is the hardest part of the design, and how to keep the scope small enough to actually get funded. It is written for campus IT, facilities, and emergency management staff who need to know what is dark before the calls start coming in.
A partial outage is a power failure affecting only part of a site, typically because the site is fed by more than one utility connection or distribution path. It is operationally harder than a total outage precisely because the site is still partly functional.
In a total outage, the situation is unambiguous. In a partial outage, every question becomes site-specific:
Without instrumentation, answering these means dispatching people to look, or waiting for occupants to report. Both are slow, and both produce a picture that is already out of date by the time it is assembled. The goal is a live map: which buildings have power right now.
Scoping is where campus power projects most often go wrong, usually by measuring more than the decision requires. The operational question is binary - is this building powered or not - and the monitoring should match.
Two clarifications narrow the problem considerably:
Monitor ordinary building power, not protected power. Anything genuinely critical on a campus is typically already on a UPS backed by an automatic generator. Those loads do not go dark, and they are not the thing anyone is uncertain about during an outage. The uncertainty is about ordinary commercial power in ordinary buildings.
You do not need to wire into the main. This surprises people, because power monitoring sounds like electrical work. An outlet-based power sensor plugs into a standard wall receptacle and holds a relay closed while power is present; when power drops, the relay opens and an RTU discrete input sees the change. No panel work, no electrician, no permit.
That second point matters for cost as much as for speed. A campus with electricians on staff can still find that scheduling panel work across thirty buildings is the most expensive part of the project. Plugging a sensor into an outlet removes that line entirely.
A small RTU with a handful of discrete inputs is all the capacity this requires, and choosing the right RTU here means choosing the smallest one that does the job. Resisting the urge to specify more is part of keeping the project fundable.
This is the central design problem, and it is worth stating plainly: a monitoring system that reports over the building's own network may lose its reporting path at the same moment it has something to report.
Campus networks are often UPS-backed, so in theory a power-fail alarm gets out before network gear drops. In practice that is a race nobody should want to run during an emergency. Two approaches remove the dependency:
| Approach | How It Works | Consideration |
|---|---|---|
| Cellular reporting | The RTU has its own LTE connection, independent of campus network and building power, and sends the alarm out directly. This is the same approach used for remote sites without wired transport. | Adds a recurring cellular cost. Requires adequate signal at the unit. |
| Polled presence | A central system polls each unit. A unit that stops answering is itself the outage signal. | Detects loss but carries less detail about the cause. |
In practice the two combine well. A cellular-equipped RTU reports the power-fail condition actively, and the polling relationship provides a second signal if the unit goes silent entirely. Either way, the reporting path has to survive the condition it reports, which is the design rule that should drive the hardware selection.
One honest tradeoff on built-in cellular: monitoring hardware often stays in service fifteen years or more, and cellular generations get retired on a shorter cycle than that. A built-in modem is the simplest design and the right answer for most deployments, but the network generation it uses is worth asking about, because it is likely to age faster than the unit around it.
The head-end is the system that collects status from every building and presents it. For campus power monitoring specifically, its location is a design decision rather than a preference.
The argument against an on-premises head-end is simple and hard to refute: if the campus loses network connectivity or power, an on-site server leaves you blind from off campus at exactly the moment you most need to see. Redundancy within the campus does not solve this, because the failure being monitored can affect the whole site.
That points toward off-site visibility of some kind - whether a hosted platform, a central alarm master reachable from outside, or feeding the data into a platform the institution already runs off site. The requirement is not a particular architecture; it is that status remains visible from somewhere the outage cannot reach.
Many campuses already run an enterprise mapping or GIS platform for facilities, space management, or security camera layouts. Where one exists, feeding power status into it is often better than adding another standalone dashboard.
The reasons are practical:
This makes API access a gating technical question rather than a nice-to-have. If the monitoring platform can expose status in a form the campus GIS can ingest, the architecture works. If it cannot, the whole design changes. It is worth confirming that compatibility before committing, not after.
Where an existing platform is not available, a map-based view is still the right presentation. A flat list of devices showing up or down is workable, but an aerial campus map with powered buildings in green and dark ones in red is the view people actually want during a crisis, because it matches how they think about the campus.
Outlet-based power sensing is reliable and inexpensive, but it measures power at one outlet, and there are situations where one outlet does not represent the whole building.
The most notable is a lost phase. A building fed by three-phase power can lose one phase, taking down the circuits on that phase while the rest of the building stays energized. A single outlet sensor will report that building as fully healthy or fully dark depending on which phase its outlet happens to sit on. Neither answer is correct.
This is rare - the kind of event a long-serving facilities staffer might see once in a career - but it is worth deciding about deliberately rather than discovering later:
The point is not that one answer is right. It is that the limitation should be stated in the proposal rather than surfacing during the first real event.
Campus projects are frequently funded in stages, and a design that assumes all-or-nothing can stall. Two practices make phasing easy.
Keep per-building cost divisible. If a campus has thirty buildings but wants to prove the concept on ten, the pricing has to divide cleanly so the people deciding can do the arithmetic themselves. Steep quantity tiers make a pilot look artificially expensive relative to the full rollout, which discourages exactly the incremental start that gets projects approved.
Plan for site variation, but price it separately. Most buildings will be straightforward - a rack on an upper floor with decent cellular signal. Some will not. Older buildings with all data infrastructure in a basement may need an external antenna run to an outside wall. That is ordinary cable work, but the count is rarely known up front, so it belongs as a per-building add-on rather than baked into every unit.
Other items worth settling early:
That last point deserves attention even when expansion is explicitly not in scope. Campus stakeholders tend to value knowing the path exists - environmental sensing, water detection, mechanical room monitoring - while still funding only the immediate need. Describing what is possible without inflating the current proposal is usually the right balance.
Usually not. An outlet-based sensor plugs into a standard receptacle and holds a relay closed while power is present, opening on power loss. No panel work is required, which removes what is often the most expensive part of a multi-building rollout.
Through a reporting path that does not depend on building power or the campus network. A cellular-equipped RTU sends the alarm over LTE. A polled architecture adds a second signal, since a unit that stops answering indicates a problem on its own.
Because a campus network or power event can leave you blind from off site at exactly the moment visibility matters most. Status should remain reachable from somewhere the outage cannot affect.
Where the monitoring platform exposes a suitable API, yes - and it is usually preferable, since staff already have accounts and campus geography is already modeled. Confirm API compatibility before committing to the architecture, since the design depends on it.
A single outlet sensor will report that building based on the phase its outlet sits on, which may not reflect the whole building. Options are to document the limitation, place two sensors on different phases in larger buildings, or monitor at the panel where warranted.
Yes, and it is a sensible way to run the project. Ask for pricing that divides cleanly per building so a ten-building pilot can be evaluated against a full rollout without quantity tiers distorting the comparison.
If your campus is fed by more than one utility connection and nobody can say which buildings are dark during an outage, the fix is smaller than it sounds: an outlet-based sensor and a compact cellular RTU per building, reporting somewhere the outage cannot reach. DPS Telecom can scope a per-building design, confirm whether status can feed the platform you already run, and price it so a pilot divides cleanly against the full rollout. Get a Free Consultation, or call 1-800-693-0351 or email sales@dpstele.com.
Andrew Erickson
Andrew Erickson is an Application Engineer at DPS Telecom, a manufacturer of semi-custom remote alarm monitoring systems based in Fresno, California. Andrew brings more than 19 years of experience building site monitoring solutions, developing intuitive user interfaces and documentation, and opt...
