Most mining operators monitor their machines. Far fewer monitor the facility those machines sit in, and the gap between the two is where expensive surprises live.

Fleet dashboards tell you a miner is offline. They do not tell you that a breaker tripped, that an intake damper failed shut an hour earlier, or that the generator has been running on one of two fuel pumps since Tuesday. That is the job of industrial controls, and at a certain size it stops being optional.

What SCADA and PLCs actually do here

A PLC, a programmable logic controller, is an industrial computer that reads sensors and operates equipment according to rules you define. It is the thing that closes a damper when a temperature crosses a setpoint, or sheds load when an incoming feed drops.

SCADA, supervisory control and data acquisition, is the layer above it: the screens, the historical record, the alarms, and the ability to see several PLCs at once. The PLC acts. SCADA is how people see what it did and why.

The distinction matters because they fail differently. A PLC keeps running the site when the network is down. A SCADA outage costs you visibility, not control. Designs that put safety-critical logic in the SCADA layer rather than the PLC have that backwards.

What this is not

It is not a replacement for fleet management software. Those tools watch hashrate, chip temperature, pool connectivity and firmware across thousands of miners, and they do that far better than any industrial control system. We cover that layer in our guide to remote monitoring and fleet management.

SCADA watches the building: power, cooling, air handling, fuel, fire, access, water. The two systems answer different questions and the useful setup is both, with the facility layer able to act on its own.

When a site actually needs it

A small air-cooled site with utility power and a handful of containers does not need SCADA. A thermostat, good alarming on the fleet side and someone within driving distance covers it.

The case gets strong when any of these are true:

• Behind-the-meter or generator power. Gensets, transfer switches, fuel systems and paralleling gear all need supervision, and the consequences of missing something are measured in equipment rather than hours.
• Liquid or immersion cooling. Pumps, heat exchangers, fluid levels and leak detection are facility systems, not miner systems, and nothing in a fleet dashboard will tell you a pump is cavitating.
• The site is remote or unstaffed. Controls that can act without a person present are the entire point.
• Curtailment participation. If you are responding to grid signals, load shed has to be reliable, fast and auditable. Our guide to curtailment and demand response covers why the audit trail matters as much as the shed.
• Multiple sites. One operator cannot hold the state of four facilities in their head.

What to instrument first

Sites that try to instrument everything at once usually end up with a lot of data and no alarms anyone trusts. A more useful order:

Power. Incoming feed, main breakers, each distribution branch. Voltage, current, power factor. This is the layer that explains most unexplained outages, and sub-metering here pays for itself in billing disputes alone.

Thermal. Intake and exhaust temperature per container or hall, plus ambient. Two sensors per space is enough to see a recirculation problem forming before machines start throttling.

Air handling. Fan status, damper position, filter differential pressure. Filter pressure in particular is the cheapest predictive signal on a mining site: it rises steadily and tells you when to service rather than waiting for a thermal alarm.

Generation and fuel, if present. Run status, fuel level, oil pressure, coolant temperature, hours. Hours matter because maintenance intervals are counted in them.

Safety. Fire detection, emergency stop status, door position. These belong in the control system even when they have their own panel, because the operator needs one place to look.

Alarms are the part people get wrong

An alarm that fires often enough to be ignored is worse than no alarm, because it trains the operator to dismiss the screen. Most new SCADA deployments generate far too many and then quietly lose their audience.

Three practical rules. Every alarm should have an action attached, and if nobody can say what to do about it, it is a data point and not an alarm. Alarms should be ranked, so that a fire signal and a dirty filter do not arrive looking identical. And standing alarms should be fixed or retired rather than left to sit, because a permanently red screen is a screen nobody reads.

What it costs and how it is usually phased

The cost is mostly labour and integration rather than hardware. PLCs, sensors and the networking between them are industrial commodities; the money goes into the programming, the screens and the commissioning.

Most sites phase it rather than building everything at once. A common sequence is to start with monitoring only, no control, so the system proves it is reading reality correctly before it is trusted to act. Then add alarming once the data is stable. Then add control, starting with the things where a wrong decision is recoverable, such as damper position, before anything that sheds load or stops equipment.

That order matters because the failure mode of a rushed controls project is a system that acts on bad data. A sensor reading twenty degrees high will happily drive a cooling system into the ground, and it will do it faster than a person would.

Questions to ask a controls integrator

• Which logic lives in the PLC and which lives in SCADA, and what happens to each if the network drops?
• Who owns the PLC program and the source for it, and do we get a copy?
• Is the hardware a standard platform with available parts, or a proprietary system only you can service?
• How are alarms prioritised, and who decides what is critical?
• What is the commissioning plan, and will sensors be verified against a known reference rather than assumed correct?
• How do we add a container next year without a rebuild?

The question about program ownership is the one most often skipped and most often regretted. A site that cannot modify its own control logic without calling the original integrator has bought a dependency rather than a system.

Security, briefly

Industrial control systems were designed for isolated networks and many still carry that assumption. A mining site that exposes its PLCs to the internet for convenience has created a problem it cannot see.

Keep control networks separate from the business and miner networks, reach them through a VPN rather than a forwarded port, change default credentials, and keep an offline copy of the PLC program. That last one is the difference between a bad afternoon and a rebuild from memory.

The practical point

Controls are not what makes a site profitable. They are what stops a site losing money while nobody is watching, and the case for them scales with how far the nearest competent person is from the equipment.

Rax Mining operates hosted facilities with facility-level monitoring on power, thermal and air handling as standard, so clients are not relying on fleet dashboards to tell them about building problems. If you are planning a site and weighing how much instrumentation it needs, speak to our team.