String-level monitoring tells you something is wrong.

It does not tell you where to park the truck.

A technician gets the alert. The next question is simple: which module?

That gap is where a lot of rooftop O&M budget quietly disappears. And it gets worse every year, because rooftop systems keep getting bigger.

Here is how it shows up in the field — and the two questions that decide how a maintenance day goes.

Rooftop PV has a scaling problem

On a small roof, O&M is a walk. A technician can see most of the array, spot the obvious fault, and be done before lunch.

That stops working once the array gets past what one person can take in.

It doesn't take thousands of modules for that to happen. A few hundred is already more than anyone can scan by eye — and a large rooftop can carry several thousand.

At that point, one underperforming module looks exactly like every other one on it. Production dips by an amount that disappears into weather noise, and nobody notices for weeks.

The usual answer is string-level monitoring. It's a real improvement — you find out that something is wrong.

But "something is wrong, somewhere on this roof" is not an action plan. String-level data narrows it to a string, and a string is maybe twenty modules. You are still sending a crew up to search.

That is the part that doesn't scale: not the fault. The search.

The module is the cheapest part of the repair

Worth saying plainly, because it reframes the purchase decision.

A failed connector costs almost nothing. What costs money is the truck roll, the crew, the day, and the production you lose while checking rows that turn out to be fine. On a large rooftop, one unnecessary search can cost more than several failed components combined.

The failed module may be inexpensive. Finding it is what costs.

So the question worth asking about any monitoring system is not "how much data does it give me."

It's "how much searching does it remove."

Question one: which module, exactly?

Module-level monitoring answers that — provided the platform knows where each module physically sits. Building that mapping is the part that takes work, and it is what Acloud EOS does first.

In the layout view, every module is an independent tile, placed one-to-one according to its actual installation position — a module-level digital twin of the array as built. Power, voltage and current are read as colour intensity rather than as rows of numbers.

So you are not tracing a device ID through a list and working out which one is on the roof above you. You are looking at the roof.

Per module, you get the things that matter in the field: operating status, live data, and the history behind it. Operating data and alerts show what needs attention; the layout shows where to go. A fault is located down to the individual module rather than stopping at the string.

On a roof with hundreds of modules, that is the difference between walking the array and walking to one place. And the data keeps building — module-level operating data accumulates as a basis for later troubleshooting and O&M analysis, not just as a reading for today.

None of this removes the site visit. The array still gets walked — it just gets walked with a destination.

Question two: can you cut power to it — safely?

The second question decides whether maintenance is routine or risky.

Under light, a PV module keeps producing DC voltage. It has no off switch. That is a property of the technology, not a defect: the moment sunlight hits the cells, there is voltage on the conductors. Any electrical work on a rooftop array has to assume that the part you are about to touch may still be live.

This is why rapid shutdown exists as a category, and why project specifications increasingly call for it — particularly where the roof is not owned by the people working on it.

MR-T2 supports module-level rapid shutdown, with three ways to trigger it.

Automatically. A local control box sends a continuous heartbeat to every unit. As long as that heartbeat arrives, the system runs normally. If it stops — the controller loses power, fails, or the link is broken — each unit enters fail-safe shutdown on its own. Nobody has to press anything, and nobody has to notice.

The detail worth pausing on: that heartbeat comes from the local controller. Not from the inverter, and not from the cloud. Which is why a dropped internet connection sits outside the shutdown logic entirely — it neither disables the function nor trips it.

Manually. An optional emergency-stop device, placed somewhere reachable, triggers the same fail-safe path directly.

Remotely. A shutdown command issued from Acloud and delivered through the data control box. Useful when the maintenance decision is made away from site.

In all three cases the result at the module is the same: that module's output drops below 1.5 V. What that does to the string as a whole depends on the rest of the system — a number to confirm on the project, not to assume.

Three ways in. One result at the module.

One thing worth being explicit about, because it is a common misreading: rapid shutdown is not the same as making a rooftop safe to touch. Modules still generate voltage in daylight — that does not change. What changes is that the state of the array is known and controlled, which is what lets a crew work to its safety procedure rather than around uncertainty.

So: rapid shutdown is an additional protection layer. It is not a claim of zero risk, and it does not replace the electrical safety practice your crew already works to.

Why we put both in one device

This is the design decision worth explaining, because it's the least obvious one.

Monitoring and rapid shutdown are usually specified, bought and installed as two separate things. Two product lines, two sets of boxes, two sets of connections, two rounds of roof work, two places for something to come loose.

Rooftop labour is the expensive part of installation. And every extra connection point on a roof — exposed to heat, humidity and whatever the weather does — is another thing that can fail later.

So MR-T2 puts both in the same device, on the module side, two modules per unit. Monitoring and rapid shutdown, integrated at the point where the modules are.

Fewer boxes. Fewer connections. Fewer points to mount, wire and maintain — and one device to diagnose when something goes wrong, instead of two.

Together with the DCON data control box and Acloud EOS, the result is a simpler relationship between what happens on the screen and what happens on the roof.

See it. Locate it. Control it when required.

What MR-T2 does not do — and what that doesn't mean

We would rather be clear about this up front: MR-T2 does not include MPPT power optimisation. It is not an optimiser, and it should not be specified as one.

The part that gets misread is what follows. This is not an either/or between MR-T2 and our MRO series. It is a deployment question, and a roof usually answers it in zones rather than as a whole.

• Standard, unobstructed areas → MR-T2. Monitoring and rapid shutdown.

• Shaded or mismatched areas → MRO. Optimisation on top of the same monitoring and rapid shutdown.

That is the difference between "optimise everywhere" and "optimise where it matters — not necessarily everywhere." On a real roof it is also a budget line: optimisation goes where it earns its cost, instead of being priced across every module on the building.

Which is why the useful question at specification stage is not "do we need module-level electronics?"

It is: what does this particular rooftop actually need — and where?

Mixed deployment has its own engineering rules, and those are confirmed at project level — not assumed from a page like this one.

When does module-level visibility start to matter?

There is no magic module count. Every rooftop is different — in size, in layout, in how its maintenance is actually organised.

But the underlying question is the same:

When something goes wrong, how quickly can you move from "the system has a problem" to "this is where we should look"?

As the array gets larger, the cost of searching grows with it. That is where module-level monitoring becomes more than another layer of data.

It gives the maintenance team a starting point.

Not just "something is wrong." But "start here."

A question for you

If you work on rooftop PV today: are you working at string level, or module level?

And has the size of your projects changed the answer? At what point did string-level data stop being enough for your team — or hasn't it yet?

That's the part I'd like to hear about.

AdvanSol MR-T2 — module-level monitoring and rapid shutdown for rooftop PV systems.

For specifications, system configuration and application conditions, refer to the technical documentation or get in touch.