With the costs of installing photovoltaic solar declining rapidly, the technology is increasingly becoming a realistic solution to support off-grid applications. The National Renewable Energy Laboratory (NREL) calculated the installed cost of solar systems in 2010 to be slightly more than $7/Watt, and SolarBuzz shows system pricing trends toward $15.50 per kilowatt-hour. This is the entire system, including the solar cells, energy storage device, and both the charger and inverter power electronics.
From portable, highway-construction signage and flashing indicators, to remote pumping stations and communication networks, the opportunities for off-grid applications are seemingly endless. Declining prices continue to reduce the significant barrier-to-entry, making projects that were once grossly cost-prohibitive a feasible reality.
We will focus on the power-electronics system and some of the key opportunities and tradeoffs to keep in mind when designing off-grid solar-based systems. As in solving most system-level problems, it is often easiest to start with the end-application requirements and work backward to identify, define, and size the entire system.
The load could be virtually anything, but an off-grid application is off-grid for a reason. The application may need to be portable, as is the case with construction information signs or simple hazard flashers. Given their portability, it is clearly not feasible to run a grid connection for each. Or perhaps the application is in a remote location, such as may be the case with a cellular communication tower or a remote pumping station.
Let us start by identifying some of the key items to consider when developing an off-grid, solar-powered solution. Figure 1 provides a high-level system block diagram. Using an energy-balance approach, the key is to understand the load, including its type and behavior over time.
Figure 1: High-level system block diagram.
The first thing to identify is the load type and any special requirements. Is it a constant or variable load? Is it only on during the day, or is it only on at night? Is it on intermittently or all the time? Understanding the load type and its behavior has an impact on the system implementation.
For instance, construction hazard flashers are typically a constant, pulsed load that likely need only be on at night. Thus, we would expect to charge them during the day, and size the battery to then run them throughout the night. An information sign maybe a pulsed load, but it would run both day and night. In this case, the system needs to be sized to support the constant load during the day, while at the same time replenishing the battery pack for continued operation throughout the night.
Similarly, a pump load needs to operate day and night, but is not necessarily a constant load. Here, the system would need to be sized to a worst-case condition, or would require a backup system to address the worst-case scenario. For instance, a pumping station that removes rain water is probably not the best application for an off-grid solar application, as there is not a lot of sunlight available to charge the batteries when it is raining. While it is clear that there is virtually an infinite number of load types, Figure 2 shows some of the load types discussed above.
Figure 2: Common load types.
The key is to understand the average daily load, given the magnitude, frequency, and the operating behavior. Once the load and operating conditions are well understood, it becomes straightforward to specify the energy-storage requirement.
Since the sun rises and sets every day, we can calculate a base energy-storage requirement using a simple energy-balance method over a 24-hour period. Consider Figure 3, which identifies the operating conditions. It should be clear that the energy storage must be sized to support the left-hand side of this table.
Figure 3: Operating states.
The load may be a well-known quantity, such as the construction hazard flashers, or have a significant amount of variation, as in the pumping application. When dealing with varying loads, it is best to consider two cases. The first case, being the ‘normal’ condition, covers the 95th percentile of operation. The energy storage element should be replenished throughout the day, and sized to drive the load through the remainder of the night. The second case is the worst-case, normal operating condition, which covers the above 95th percentile group (i.e., the pump starts at dusk and runs at full load throughout the night). The equation below captures the worst-case energy storage requirement, by consolidating the maximum hourly load power during the period of time not spent charging.
There is an even worse, worst-case condition, if we consider the impact of not having a fully charged battery pack when the above situation arises. A key consideration is the cost of failure (i.e., not flashing or not pumping). The costs may be significant if the pump does not pump. One clear mitigation technique is increasing the size of the energy storage element. There is always, however, a more detrimental, worst-case condition. In situations where failure cannot be tolerated, or where the maximum power required is rare, it may make the most sense to have a backup system, such as a diesel-generator, and size the rest of the system for just the normal case.
While the left-hand side of Figure 3 captures the energy storage requirements, the right-side of Figure 3 can be used to size the solar array.
With a better understanding of the load requirements, we can size the solar array. Utilizing Figure 3, the solar array must be sized to replenish the energy storage capacity within the specified charging time, while supporting the average load output during that same time period. The equation below identifies this high-level relationship.
A simplified energy-balance approach enables us to estimate the size of the energy-storage and solar-array components. There are, however, additional factors, both internal and external, that we need to understand in order to fine tune those sizing estimates. From an external-factors standpoint, one of the most critical is the location, specifically the latitude, of the off-grid application. This, alone, will determine the peak amount of solar exposure that can be expected, as well as its variation over the course of a year. For instance, we would expect the amount of solar exposure to be at a minimum during the winter months, and at a maximum during the summer, simply due to its position relative to the sun. There are additional external factors, including cloud cover and ambient temperature that may also adversely impact the amount of sunlight the system can expect to receive, as well as the efficiency of the energy conversion. It should be clear that these external factors will vary by both application and location.
Additionally, internal factors, such as the system architecture (specifically, how things are interfaced), will impact the component sizing. Unfortunately it is just not possible to achieve 100 percent conversion efficiencies, so there will be losses that must be accounted for. In the above discussions, the energy-storage and solar-array sizes identified the delivered energy and power. To calculate the power that needs to be generated requires consideration of the power electronics.
Power electronics topology
While the system block diagram found in Figure 1 is useful for an understanding of energy balance, to consider the internal factors that impact the component sizing requires more detail. Figure 4 provides a more descriptive picture of the system implementation. It also raises questions, each of which impact the power-electronics strategy.
A microcontroller-based power strategy offers significant flexibility. It allows a standard reference design to be used over a wide variety of applications, while still allowing application-specific needs to be addressed and advanced functions implemented. Not only can it support the base power conversion, it also offers flexibility in the selection of core components, supports changes and allows for optimization over a wide variety of operating conditions. Further, advanced features such as communication and diagnostics may be easily implemented. This would not be feasible with a dedicated, stand-alone power converter.
In this implementation, the biggest questions come from the load. The primary items include such questions as what is the nature of the load, and what does the ‘load control’ need to look like? Does it need a voltage or a current? How precise or accurate does that voltage or current set point need to be? The load control may be as simple as a relay or as complex as a 3-phase inverter. In any case, we see that it will require a charger function (i.e., power electronics), which uses the solar power to charge the energy-storage device. If the system allows, it can offer a maximum peak power tracking (MPPT) capability.
Figure 4: Detailed system architecture overview.
Perhaps one of the first decision points is whether a common- or distributed-power rail architecture should be used. Figure 5 demonstrates the differences, although the load behavior will likely drive the selection. The common rail illustrated in Figure 5a may be the best choice, if the load requires a constant voltage. In that case, the Load Controller becomes a simple relay or solid-state switch. The Solar DC/DC keeps the common rail at the voltage set point, and the Battery Charger takes power off the bus to charge the energy-storage device. The advantages and disadvantages to this approach are the power-conversion steps. Considering 85 percent average power-converter efficiency, that means 15 percent in losses per conversion. If the solar DC/DC is able to support the load, then it becomes just a single power-conversion step. However, to charge the battery requires two power-conversion steps (solar DC/DC to common-rail and common-rail to Bi-Directional DC/DC), plus an additional conversion (Bi-Directional DC/DC to common-rail) to support the load.
A common-rail may also be used, if the load is only used when the solar DC/DC is not working (i.e., at night). In that case, the Solar DC/DC can be eliminated and the Bi-Directional DC/DC on the energy-storage device can be used to charge the battery from the solar array or, as an alternative, can be used to supply the load. In this case, the energy need only go through two power-conversion steps (solar DC/DC to Bi-Directional DC/DC, and Bi-Directional DC/DC to the load).
The distributed architecture in Figure 6 is more flexible and can support varying load requirements. In this case, the solar DC/DC can be used to support the energy storage rail (i.e., charging), and the DC/DC converter can support the load requirements. The downside of this approach is that there are always two power conversions. Overall, if the solar array and load can be expected to operate concurrently, this is the superior solution.
Figure 5: Power rail architectures.
A brief example
Given this high-level review of the power architecture, we can now review a simple low-power example. Consider a “construction zone hazard flasher,” which is commonly found on the top of construction barrels and concrete barriers. From a high-level perspective, the flashers work only at night and the battery will recharge at all other times. This behavior allows us to use the common-bus architecture, and since they are either charging or flashing, but never both, we can further simplify the topology by combining the Solar DC/DC, bi-directional DC/DC, and the load control together into a single, bidirectional converter. The proposed circuit design is found in Figure 6: Proposed Circuit Diagram.
Figure 6: Proposed circuit diagram.
This proposed circuit design uses a Microchip PIC16F690 and two MCP1630 Analog PWM controllers to drive a bidirectional flyback converter. During the day, this arrangement uses the solar power as the input and charges the battery. During the night, as detected by low to no power on the solar array, the converter starts providing power with the programmed ‘flashing’ pattern to the LED light. Table 1 captures the assumptions and calculations.
Table 1: Application assumptions and results.
Distributed applications will continue to take advantage of the progressive decline of solar installation costs. The end application requirements drive the system topology and highlight the key performance tradeoffs. A microcontroller-based power-conversion architecture enables a great deal of flexibility, both in its ability to support a diverse array of end applications, as well as its ability to support continuing advances in photovoltaic solar technology. This flexibility means that designs made today will continue to be relevant tomorrow.