For communities

The control system behind your water plant, in plain terms

Every water plant, pumping station and heating plant has a control system: a set of small computers that read sensors, tank level, chlorine, pressure, temperature, and drive pumps and valves according to rules written when the plant was built. A screen in the plant, or a laptop, shows the operator what those computers see. The screen and the rules together are the SCADA system.

Three things are usually true of it. It was installed by the contractor who built the plant, to that contractor’s design. It has run for ten or fifteen years on hardware its maker may no longer support. And the only description of how it works is in the head of the operator, or in a binder that left with the contractor.

None of that is a fault; it is how most small plants are built. It becomes a problem the day the operator retires, a controller fails and cannot be replaced like for like, or a funder or an insurer asks for a description of the system and there is none.

The first step is not new equipment. It is a written baseline: what is installed, how it is connected, what is out of support, and which single part would stop the plant if it failed. Every later decision, replacement, monitoring, funding, is made from that document.

Related: SCADA and control-system baseline →

Why the office network and the control network must not be the same network

A community’s office network carries email, web browsing, the finance system and everyone’s laptop. The control network carries the commands that run pumps, valves and generators. When they are the same network, anything that reaches a laptop, a phishing email, an infected USB key, a contractor’s remote-access tool, can reach the plant.

Separating them does not mean two buildings or two internet connections. It means the control network is its own zone, joined to the office network through one controlled point that passes only the traffic it is meant to pass, and keeps a log of it. The operator still sees the plant from the office; the plant no longer sees the office.

This is the core of IEC 62443, the international standard for securing industrial control systems, and of the ISA-95 model that describes the levels between a sensor and a business system. Neither requires new controllers. They require knowing what talks to what, then placing a boundary where one belongs.

Canada’s Critical Cyber Systems Protection Act, passed in 2026, makes such programs mandatory for designated operators in federally regulated sectors. Community systems are not designated today. Funders and insurers ask the same questions all the same.

Related: IT/OT architecture and segmentation review →

How much power a site really needs

The generator at a radio site or a water plant is usually sized for the worst hour anyone could imagine, then rounded up. What the site draws most of the time is a fraction of that. Knowing the real figure, the average load, the peak, and how long the site must keep running when supply fails, is the whole basis of a power design.

Three numbers do it. Average draw, in watts, from a meter on the feed for two weeks. Peak draw, when a pump or a compressor starts. Autonomy: how many hours or days the site must ride through an outage. From these, the size of a battery bank, a solar array or a backup generator follows by arithmetic.

Solar-plus-storage works well for communication and control sites, whose loads are steady and modest, when it is sized to the real draw and to the winter rather than the summer. It works poorly for a site sized on a guess, which is how most systems end up either short in February or three times larger than needed.

Regulated electrical design is stamped by a licensed engineer. The load study that comes before it is not, and it is the part most sites skip.

Related: energy audit of communication and control sites →

Fibre, fixed wireless, satellite: what each one is good at

Fibre carries the most, for the longest distance, with the least delay, and does not care about weather. Its cost is in the ground: every kilometre of trench or pole line, and the right to use it. Once built, it lasts decades.

Fixed wireless, a radio link between two towers, or from a tower to a building, carries less than fibre, needs line of sight, and is affected by ice and foliage. It can be built in months rather than years, for a fraction of the cost, and is often the right way to reach the last sites a fibre route cannot justify.

Satellite reaches anywhere with a view of the sky. Geostationary satellites are far away, so every exchange carries a noticeable delay; low-orbit constellations are close and fast but depend on a private company’s network and ground stations, which for most Canadian users are outside the country. Weather and capacity limits apply to both.

Resilient sites use two of the three, so that a cut cable or a failed link does not stop the clinic or the water plant. Which two depends on the geography, the sites that matter most, and what already exists: which is what a readiness assessment establishes.

Related: broadband technology options analysis →

What a repeater site is, and what it needs to keep working

A repeater site is a high point, a tower, a hilltop, a tall building, where a radio receives a signal and sends it on, extending a radio network or a wireless link beyond line of sight. A radio quote describes the antenna and the equipment. The site is everything else.

Everything else: a shelter or cabinet that stays dry and within temperature; power that keeps running through an outage; a road or trail someone can use in February; a lease or permission for the land; grounding and lightning protection; and a way to know from a distance that the site is up.

Most repeater failures are site failures, not radio failures: a battery that froze, a door that let snow in, a lease that lapsed, an access road that did not exist when it was needed.

A feasibility study for a site covers the whole of it, link, shelter, power, access, lease, and prices the parts the radio quote leaves out. It is the difference between a network that works in the demonstration and one that works in March.

Related: fibre route and repeater-site feasibility →

How to measure your real internet speed so the number holds up

A provider’s advertised speed is “up to”. What a site actually gets varies by time of day, by the number of people using it, and by the link itself. A single test on a quiet afternoon proves nothing; a record proves something.

The method: test at the same site, on a wired connection where possible, at two times on a weekday, mid-morning and mid-afternoon, for two weeks, with the same test each time, noting download, upload and latency. Keep the lower of each day’s two results. What you have at the end is a figure that reflects what the site experiences, not the best case.

The CRTC’s universal service objective is 50 megabits per second down and 10 up. Whether a site meets it is a question of measurement, and the measurement is what a funding program or a service-level discussion turns on.

The speed test guide in the free templates gives the procedure and a log to record it in.

Related: the free connectivity templates →

Where your community’s data actually lives

A community’s membership list, housing files, health records, water-quality logs and financial records live in software. Most of that software is now a service: the data is stored by the vendor, on servers the vendor chooses, under a contract the vendor wrote.

For satellite internet users, even the traffic on its way to those services passes through ground stations that, for most Canadian users, are outside the country. That is not a fault; it is how the systems are built. It matters when a community wants to say, truthfully, where its data is and who can reach it.

OCAP®, ownership, control, access and possession, is the First Nations statement of what data governance means. In practice it comes down to a few questions: what do we hold, where is each part, who controls it, under which contract, and could we take it back. A data inventory answers them; the rest of governance is built on the inventory.

Québec’s Law 25 and PIPEDA add obligations of their own: who is responsible for personal information, how it is protected, and what must happen when it is lost.

Related: data inventory and residency mapping →

What a cloud or software contract should say about your data

Most contracts for software and cloud services are written by the vendor and accepted as they come. Four clauses decide whether a community keeps control of its data. Residency: where the data is stored and processed, named as a country or a region, not “our secure facilities”. Access: who at the vendor can see it, and whether the vendor may use it for anything but providing the service.

Exit: how the community gets its data back, in what format, at what cost, within how many days, if it changes vendor or the vendor closes. Breach: what the vendor must tell the community, and how soon, if the data is lost or exposed.

A contract that is silent on any of these is not neutral; the silence favours the vendor. Asking for the four clauses before signing costs nothing and is normal practice. Asking afterwards costs whatever the vendor decides.

This is a technical review of what a contract says about systems and data. It is not legal advice; counsel reads the contract as a whole.

Related: cloud and vendor agreement review →

How to read a provider’s proposal

A proposal is written to be accepted. Six things to check before the price. What exactly is promised, speed, availability, coverage, and is it measured, or “up to”? What happens when it fails: response time, repair time, and what the community receives when the promise is missed? Who owns what is built, the cable, the tower, the equipment, and can the community buy it?

What the contract costs to leave: term, renewal, exit fee? What is not included: site power, the access road, permits, the equipment inside the building? And what the provider needs from the community, consent, land, a letter of support, and what that letter commits the community to?

A provider that answers those six with numbers is a provider whose numbers can be checked later. The provider vetting guide in the free templates has twenty such questions, with what a good and a weak answer look like.

Related: telecom contract and SLA technical review →

What “funding-ready” means

Every infrastructure program, federal, provincial, CRTC, asks for a version of the same file: evidence of the current situation, a statement of need, the options considered, the one chosen and why, its cost over its life, and proof that the community was consulted and consents.

A reviewer is not looking for a good story. They are looking for whether each claim has something behind it: an inventory rather than “our internet is bad”; measured speeds rather than “slow”; an outage log rather than “it goes down all the time”; a load study rather than “we need a bigger generator”.

“Funding-ready” means the file could be handed to a stranger who could check every figure against a document inside it. The knowledge is usually there; the record often is not. The templates and the studies exist to produce the record.

Related: feasibility study and options analysis →