Sizing the solar array is the step where a remote SCADA site's power budget turns into a real panel wattage you can order. It sits downstream of working out the daily load and upstream of choosing the battery, and it is where most undersized field sites go wrong, because the arithmetic is deceptively simple but every shortcut in it comes back as a dead RTU in December. The method walks from the daily energy the site consumes, through the sunlight actually available in the worst month, through the losses that eat into what the panel delivers, and finally to a standard panel size rounded up with margin. This page lays out that calculation end to end.
Solar Panel Sizing (Remote SCADA) in one line: You size a remote SCADA solar panel by taking the site's daily energy load in watt-hours per day, dividing it by the worst-month peak sun hours to find the raw array wattage needed, then dividing again by a system-loss derate factor to account for panel heat, soiling, wiring, charge-controller, and orientation losses, and finally rounding up to the next standard panel size with margin. The daily load comes from your power budget, the peak sun hours from irradiance data for the site's location in its worst solar month, and the derate factor bundles the real-world losses that make a panel deliver less than its nameplate. Sizing against the worst month, not the annual average, is what keeps the site alive through winter.
The input to array sizing is the daily energy the site consumes, expressed in watt-hours per day, which comes out of the power budget you build by adding up the average draw of the RTU, radio, transmitters, and any other load and multiplying by twenty-four hours. This number, not the peak wattage of the equipment, is what the panel has to replace each day, and it is the anchor of the whole calculation. If the daily load is wrong, everything downstream is wrong, so it is worth getting the average draw of each device honest, including the duty cycle of anything that runs only part of the time, before going any further.
The second input is how much usable sun the site actually gets, and the correct figure is not daylight hours but peak sun hours, the number of equivalent hours of full-strength sunlight the location receives per day. A site might have ten hours of daylight but only three or four peak sun hours once you account for the sun being weak near sunrise and sunset and for the angle of the panel. Peak sun hours vary by location and, critically, by season, and you pull the worst-month figure for the site from solar irradiance data rather than guessing, because that worst month is what your array must survive.
The reason you use the worst month rather than the annual average is the single most important judgment in field solar sizing. A panel sized against the yearly average will generate plenty in summer and fall badly short in winter, and a SCADA site that browns out for the darkest weeks of the year is a failed site regardless of how well it performed the rest of the time. So the peak sun hours that go into the sizing are the lowest monthly figure the site will see, usually a winter month for a site far from the equator, and the array is built to meet the daily load even in that worst month, accepting that it will comfortably overproduce during the sunnier months.
With the daily load in watt-hours and the worst-month peak sun hours in hand, the first calculation gives the raw array wattage: divide the daily load by the peak sun hours. A site drawing, for instance, a certain number of watt-hours per day at a location with a given worst-month peak sun hours yields a wattage that, if the panel were perfect, would exactly replace the daily load. That figure is the starting point, but it assumes the panel delivers its full nameplate wattage under real conditions, which it never does, so it has to be inflated to cover the losses the field imposes.
Those losses are captured in a derate factor, which is the product of several separate loss factors applied together. The main contributors are the panel running hotter than its rated test temperature and losing output as it heats, dirt and dust soiling the glass and blocking light, resistive losses in the wiring, losses in the charge controller as it moves energy from panel to battery, and any shortfall from a tilt or orientation that is not perfectly aimed at the sun. Each of these knocks a slice off what the panel delivers, and multiplied together they typically leave you with meaningfully less than the nameplate, so the raw wattage is divided by this derate factor to find the nameplate wattage the array actually needs.
It is worth being deliberate about each loss rather than applying a single vague fudge factor, because the losses differ by site. A hot desert site suffers more temperature loss than a cold northern one; a dusty or snowy site suffers more soiling; a long cable run suffers more wiring loss; a fixed panel at a compromised angle suffers more orientation loss. Building the derate as an explicit stack of these factors makes the sizing defensible and lets you see which loss dominates at a particular site, which is far better than pulling a round derate number out of the air and hoping it covers reality. The output of this step is a nameplate array wattage that, after all real losses, will still meet the daily load in the worst month.
The derated wattage is almost never a number you can buy off the shelf, so the final step is to round up to the next standard panel size, and the direction of that rounding matters. You always round up, never down, because rounding down to save a few watts means designing the site to just barely miss its own load in the worst month, which defeats the entire point of the exercise. Rounding up to the next available panel builds in a margin that absorbs the inevitable optimism in the load estimate, an unusually cloudy worst month, gradual panel aging, and the extra soiling that accumulates between maintenance visits. That margin is not waste; it is the difference between a site that rides through a bad stretch and one that dies in it.
There is a natural coupling here with the battery, which is sized separately to carry the site through days with little or no sun, so the panel and battery are designed together as a system rather than in isolation. The panel is sized to replace the daily load and recharge the battery during a normal worst-month day, while the battery is sized to hold enough reserve for the run of cloudy days when the panel cannot keep up. A generously rounded panel helps the battery recover faster after a cloudy stretch, so the two decisions reinforce each other, and it is common to revisit the panel size once the battery and its recharge needs are known.
Once the site is installed, a cloud SCADA platform such as Merobix is what tells you whether the sizing was right rather than leaving you to find out when the site dies. By trending the panel current or charge input, the battery voltage and state of charge, and the actual load over days and seasons, staff can see whether the array is genuinely replacing the daily load through the worst month or quietly falling behind, and they can catch a panel that is underperforming from soiling, shading, or a wiring fault before the battery is drained. This turns solar sizing from a one-time paper calculation into something verified against reality, and it lets an operator distinguish a truly undersized array from a temporary bad-weather dip or a maintenance problem, which is exactly the distinction that decides whether you add a panel or just clean the one you have.
Because a site sized to the annual average will generate plenty of power in summer and fall short in winter, and a SCADA site that browns out during the darkest weeks of the year has failed regardless of how well it did the rest of the time. Sizing against the lowest-sun month, usually a winter month for sites far from the equator, guarantees the array meets the daily load even at its worst, at the cost of overproducing in the sunnier months. That overproduction is simply the price of reliability, and it is far cheaper than a site visit to a dead RTU in the middle of winter.
Daylight hours is simply how long the sun is above the horizon, while peak sun hours is the number of equivalent hours of full-strength sunlight the location receives, which accounts for the sun being weak near sunrise and sunset and for the panel's angle. A site can have ten hours of daylight but only three or four peak sun hours, and it is the peak sun hours figure, not the daylight figure, that goes into panel sizing. Using daylight hours by mistake dramatically overestimates the available energy and leads directly to an undersized array.
Yes. The derated wattage the calculation produces is rarely a standard panel size, and you round up to the next available panel rather than down, because rounding down designs the site to just miss its own load in the worst month. Rounding up builds in margin that absorbs optimism in the load estimate, an unusually cloudy worst month, panel aging, and soiling between maintenance visits. That margin is the buffer that keeps the site alive through a bad stretch, so it is a feature of good design rather than wasted capacity.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.