There is a tempting shortcut in solar sizing where you take a location's average sun for the year, run the numbers once, and call the array sized. For a remote SCADA site that shortcut is a slow-motion failure, because the average hides the winter, and the winter is when the site actually needs the power. Worst-month design is the discipline of throwing out the average and sizing the whole system against the single least-sunny month the site will face, so that the array that comfortably overproduces in July still carries the load in December. This page explains why the worst month rules, how the load-to-insolation ratio finds it, and why a summer-sized array quietly browns out an RTU in winter.
Worst-Month Design in one line: Worst-month design is the practice of sizing a remote solar power system against the month with the least available sun relative to the load, rather than against the annual average, so the system meets its load even at the worst point of the year. You find that month by computing, for each month, the ratio of the load to the month's available sunlight, and the worst month is the one where that ratio is highest, meaning the sun struggles most to cover the load. Sizing to the annual average instead leaves the array short in winter, which is exactly when a SCADA site needs its power, so worst-month design is what keeps the site alive through the dark season.
The core reason worst-month design exists is that a remote SCADA site has no tolerance for a seasonal shortfall. The site has to run every single day, and if the array cannot meet the load during the darkest month, the battery slowly drains through that month until the RTU dies, no matter how much surplus the array produced in summer. Averages are the wrong tool for a requirement like this, because an average is dominated by the good months and papers over the bad one, and it is precisely the bad month that determines whether the site survives. Sizing to the average is sizing to a month the site will comfortably beat while ignoring the month that will kill it.
This is a fundamentally different design philosophy from sizing a system where occasional shortfalls are acceptable. A grid-tied installation aiming to offset a yearly electricity bill can reasonably size to the annual average, because a shortfall in winter is just made up by drawing from the grid and the annual energy balance is what matters. An off-grid SCADA site has no grid to fall back on, so there is no averaging out a bad month; each month must stand on its own, and the design is governed by the single worst one. The consequence is that off-grid systems are deliberately oversized relative to their annual average, and that oversizing is not waste but the direct result of designing for the worst case rather than the typical case.
The worst month is usually a deep-winter month for a site far from the equator, because that is when the days are shortest and the sun is lowest and weakest, but it is not automatically the same month for every site or every load. The right worst month is the one where the site's load is hardest to meet with the available sun, and while that is often the darkest month, a site whose load is seasonal, higher in winter for heating or higher in summer for cooling, can have its worst month shifted by the load rather than the sun. That is why worst-month design does not just pick the darkest month by default; it compares load against sun month by month to find the genuine worst case.
The tool that identifies the true worst month is the load-to-insolation ratio, computed month by month. Insolation is the sunlight the site receives, expressed for sizing as that month's peak sun hours, and the load is the energy the site consumes. For each month you form the ratio of the load to that month's peak sun hours, which measures how hard the sun has to work to cover the load in that month, and you do this for all twelve months. The month with the highest ratio is the worst month, because it is where the smallest amount of sun is being asked to carry its share of the load, and that is the month the whole system must be sized to satisfy.
Working the ratio month by month rather than assuming December matters because it catches the cases where the load, not just the sun, drives the worst case. If the load is flat across the year, the worst month falls out as simply the month with the fewest peak sun hours, which is the intuitive deep-winter answer. But if the load rises in winter, perhaps because something on the site draws more power when it is cold, then the ratio in the winter months is doubly bad, low sun against high load, and the worst month is even more pronounced; conversely a summer-peaking load can pull the worst case toward a shoulder month where sun is only moderate but load is high. The ratio surfaces whichever combination is genuinely hardest to serve.
Once the worst month is identified, its peak sun hours becomes the value that feeds the panel sizing and its load feeds the battery sizing, so the whole downstream calculation is anchored to that single worst-case month. Everything else about the year is, in a sense, ignored for sizing purposes, because if the system can carry the load through the worst month it can certainly carry it through every better month. This is what makes worst-month design tractable: rather than trying to satisfy all twelve months at once, you find the one hardest month with the ratio and design for it, confident that meeting it means meeting the rest. The overproduction in the easier months is simply the unavoidable byproduct of guaranteeing the hard one.
The failure that worst-month design prevents is concrete and common: an array sized against summer sun, or against the annual average, works beautifully for most of the year and then quietly starves the site through winter. Through spring, summer, and autumn the array easily meets the load and keeps the battery full, so the site looks perfectly healthy and passes every check. Then as the days shorten and the sun weakens, the array stops fully replacing the daily load, and each short winter day the battery ends a little lower than it started. Over weeks that slow deficit compounds, the battery works its way down toward its floor, and eventually the RTU browns out and drops offline, often in the middle of the worst weather when a site visit is hardest.
What makes this failure so insidious is its delay and its timing. The undersizing is baked in at design but does not show for months, so the mistake and the consequence are separated by a whole season, which makes it easy to blame the winter outage on the battery, the panel, or the weather rather than on a sizing decision made the previous summer. And because it strikes in deep winter, it strikes when access is worst and the load may even be highest, so the site fails at the moment it is most costly to recover. Worst-month design exists precisely to break this pattern by ensuring the darkest month was the design point from the start, so the winter the shortcut design dies in is the winter the properly sized system was built for.
A cloud SCADA platform such as Merobix is what lets an operator catch a worst-month problem before it becomes a winter outage, and even validate the design over its first year. By trending battery state of charge across the seasons, staff can watch whether the battery is holding through the shortening days or drifting downward as winter approaches, which reveals a marginal or summer-biased design while there is still time to add a panel or shed load rather than after the site has died. Comparing the actual delivered sun against the peak sun hours the season should provide tells them whether a downward drift is a genuine sizing shortfall or a temporary bad-weather stretch, and watching how low the battery gets in the real worst month confirms whether the worst-month design left the margin it was supposed to. Across a fleet of sites this seasonal visibility turns worst-month design from a one-time calculation into a standing check that each site is genuinely sized for the winter it has to survive.
Because an off-grid SCADA site has no grid to fall back on, so a shortfall in the worst month cannot be made up later, and each month must stand on its own. The annual average is dominated by the good months and hides the bad one, so a system sized to the average is well supplied most of the year but falls short in winter, which is exactly when the site needs its power and when a failure is most costly to recover. Averaging is appropriate only where occasional shortfalls are acceptable, such as grid-tied systems, not for a site that must run every day on its own power.
The load-to-insolation ratio is, for each month, the site's energy load divided by that month's available sunlight expressed as peak sun hours, and it measures how hard the sun must work to cover the load in that month. You compute it for all twelve months, and the month with the highest ratio is the worst month, the one where the least sun is asked to carry the load. That worst month then anchors the panel and battery sizing. Working it month by month, rather than assuming the darkest month, catches cases where a seasonal load shifts the worst case away from midwinter.
An array sized against summer or annual-average sun produces plenty of power for most of the year, so the site looks healthy and passes every check through spring, summer, and autumn. As winter arrives and the sun weakens, the array stops fully replacing the daily load, so the battery ends each short day a little lower, and over weeks that slow deficit compounds until the battery hits its floor and the RTU browns out. The failure is delayed by a full season from the design mistake and strikes in deep winter when access is hardest, which is exactly the outcome worst-month design is meant to prevent.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.