The Process
The design process for this project followed four broad phases. First, a research survey was performed to attempt to find preexisting solutions to the problem, and evaluate any existing solutions to see if improvements could be made. This research was used to justify the existance of this project.
Second, a list of requirements was made so that the final project could be evaluated based on real, scientific criteria. These requirements were based on both the research done, the needs, and the wants of the client.
Then a design was proposed by evaluating different methods of accomplishing each function of the desired product. The prototype product would be a combination of each of these "best" ideas.
Finally, the prototype-test-design cycle was started. Each prototype was tested based on the requirements of the project. Any shortcommings were evaluated and the design was adjusted as necessary. A new prototype was developed based on the new design and the process was begun anew.
Research Survey
The current state of solar tracking technology is fragmented and non-standardized. There are two major technical solutions to solar tracking: light-sensing and chronological. Light sensing trackers measure the sunlight intensity at various angles relative to the panel orientation and then orient the panel to point toward the direction of maximum intensity. Chronological trackers use the current date, time and location of the panels to calculate the expected bearing to the sun, and orient the panel to point in that direction. Both technologies are accurate enough to orient the panels towards the sun, and so gain an expected 25 %–40 % efficiency over a stationary system. However, each technology has its advantages and drawbacks.
Light-sensing trackers are "dumb" devices; they aren't tracking the sun per se but instead the highest light intensity. Normally, this is not a problem, but on overcast days or in periods of intermittent shadowing, the panel can become confused and track "fake" suns endlessly. This excessive tracking consumes additional power and increases wear on the tracking structure and actuators. These types of trackers also cannot recognize when a panel's orientation is so extreme as to cause shadowing on other adjacent panels. In this situation, the desired behavior is to hold the panels short of the sun's inclination to maximize the illuminated panel area rather than the illumination intensity. The advantage of a light-sensing tracker is its simplicity. Because these devices are "dumb" they require fewer components and a shorter development time.
Chronological trackers are "smart" devices; they use programming to make pre-determined decisions about where the panels are oriented. The disadvantages of systems of this nature are the complexity of the devices. The controllers need significant processing power relative to the light-sensing trackers, and the ability to keep track of the date and time. The benefits of a chronological tracker, however, are great. Because they require on-board processing power, advanced features such as responding to shadowing, wind loading, snow loading, and obstacle detection are relatively simple.
Current consumer solar tracking systems are predominantly of the light-sensing type. These systems are small and inexpensive, but require large, heavy mounting systems to account for the lack of wind-load protection and are susceptible to constructive oscillation. Constructive oscillation occurs when a light-sensing system experiences vibration or shaking from wind or other phenomena. The light sensor can interpret this shift in position as a movement of the sun, and compensate. This process repeats, accelerated by the motion of the panel, causing both excessive tracking and possible destruction of the structure and actuators.
An ideal solar tracking system would use either of these technologies but be smart enough to ignore constructive oscillation and shadowing and be able to respond to high-wind situations and obstacles. Because these features all require additional processing power and knowledge of the panel's desired and actual orientation, it makes sense to use a chronological tracking system for this ideal product.
Requirements Gathering
Marketing requirements have been established to better appeal to the consumer. These requirements fit into the following categories: mechanical, electrical, environmental, testing, documentation, and general.
Mechanical Requirements
Mechanical requirements were established to increase the robustness and ease of use. The system's components must be small enough to mount on the solar tracking frame, and also be protected from the elements. In addition, standard interconnects between the controller and all sensors must be standardized and weatherproof. The system must be organized for easy maintenance. The weight and size of the panels dictates the type of actuators chosen. The system must be able to control these actuators.
- Less than 5 ft³ and under 40 lbs
Electrical Requirements
The widest possible tracking range must be accomplished to track the sun from horizon to horizon. The system's electrical components and peripherals must also be robust enough to function beyond the point of return on investment.
- For 99 % accuracy, ±5°
- Operate for 10 years (twice the Return On Investment period)
Environmental Requirements
Environmental factors must be considered to ensure the reliability of the system under harsh conditions. All components must be protected from the elements, and resistant to any related vibration or shock encountered during turbulent weather. All components in said system require industrial temperature ratings.
- Wind-driven rainfall (NEMA–4)
- Industrial temperature range (−20 °C–70 °C)
- Survive winds of up to 40 mph in tracking position
Documentation Requirements
In order to maintain the procedures and knowledge regarding the installation and upkeep of the system, detailed documentation will be required. Any and all coding used in the project will be amply annotated. The platform on which the code is written will depend of course on the programmable logic controller and its associated software. In addition, an operator's manual that includes the installation process will be developed. Finally, a maintenance/system manual detailing the system and its components will be created to support the maintenance of the photovoltaic array.
- Annotated Code
- User's Manual
- System/Maintenance Manual
Testing Requirements
A written test plan will be established to evaluate system performance. Test equipment will be provided by Sedona Energy Labs to test system hardware and software. Test equipment will include the PLC, sensors, actuators, frame, and solar panels. Testing will log sensor input and actuator activity to determine the effectiveness of the system prototype. Testing results will drive the engineering process to a refined product.
- Test plan
- Method of collecting and analyzing results
General Requirements
The system must also adhere to general desirable functions and requirements. A self-calibrating system is extremely desirable, such that the current panel azimuth and elevation can be measured. Simple setup, installation, maintenance, and programming are strongly emphasized due to the client's marketing focus.
Design Decisions
System Controller
Overview
The system controller is the brain of the sun tracking apparatus. The controller is responsible for collecting data from the various inputs (wind speed, snow load, panel orientation, sun position, maintenance requests, etc.) and intelligently using that data to control the outputs of the system (panel actuators and indicators). Because the controller interfaces between all of the other system components, it will dictate many of the options and choices for the other components. It is for this reason that the controller was selected first.
Three options were considered for the controller, a programmable logic controller (PLC), a microcontroller (MCU), and a field programmable gate array (FPGA). The specifics of each are described below. Each option was then rated in several categories representing the various needs of the system as a whole. Each category was weighted relative to the others in how important it was to the operation and development of the system. Each controller option was then assigned a composite score by summing the option's category ratings multiplied by the category weighting. These categories and weightings are also described below. The option with the highest composite score was chosen for the final design.
Options
Programmable Logic Controller
The PLC is a generic term for a device specifically developed for use in industrial control applications. PLCs and their connected components are largely modular, and are designed to be compatible with standard input and output schemes and components can generally be exchanged for those provided by other manufacturers with little to no impact. These facts make PLCs extremely easy and fast to work with. Another advantage of PLCs is that, because the hardware is designed to be universal, operational changes or upgrades usually involve only a software update (software being significantly cheaper to modify than hardware). This universality comes with a cost: PLCs are significantly more expensive per unit than an equivalent system using an MCU or FPGA would be. The money saved during development is offset by an increase in production cost. PLCs are also not particularly low-power products and their power consumption is usually in the 1-50 Watt range. In a word, PLCs are modular.
Microcontroller
An MCU is characterized by its stripped-down structure. An MCU contains no hardware that is not absolutely essential, relying on the programmer to implement all the system functions. Compared to a PLC, a MCU requires significantly higher development costs (at least an order of magnitude) but the per-unit cost is reduced drastically. The MCU also leads the field in low-power applications, with some MCUs having idle power draws in the micro-Amp range. The downside of an MCU for controller applications is that the entire controller must be developed from the ground up, requiring extensive design-prototype-test cycles, each requiring more time and money to be spent. Also, MCUs are more likely to need hardware updates in addition to software when changes are made as their hardware is custom built rather than universal. In a word, MCUs are low-power.
Field Programmable Gate Array
A FPGA is a device designed to perform fast logical operations, while remaining software programmable. This means that the FPGA sits between the PLC and MCU on almost all measures of performance. A FPGA has lower power requirements than a PLC but higher than an MCU. Development cost is much closer to that of a MCU as they share the same development process. The biggest advantage of a FPGA is their unparalleled speed; FPGAs can perform a number of simultaneous operations only limited by the FPGA's size. However, FPGAs are not well suited to interfacing with the real world, requiring external analog-to-digital and digital-to-analog converters. In a word, FPGAs are fast.
Categories
Each of these three options was rated in ten categories, each detailed below. The rating given was between one and five, with five meaning the option excelled in this category, and one representing very poor performance. Other elements of the design discussed in this proposal are rated in most or all of the following categories as well.
Cost
Cost is a measure of the cost of each unit produced. A rating of five is inexpensive to implement, while a one is very expensive.
Ease of Integration
Ease of Integration represents the simplicity of interfacing this option with other components in the tracking system. A rating of five means the option is very compatible with other devices, and a one represents an esoteric option or one that would require significant work to integrate.
Accuracy
Accuracy represents how well this option will allow the system to correctly track the sun. A rating of five means the option has almost unlimited accuracy, while a one represents serious accuracy limitations.
Power
Power represents the relative power efficiency of the option. A rating of five is an option that uses little power or uses it very efficiently, where a one represents significant power usage.
Durability
Durability represents the ability of the option to withstand harsh environments, either natural or industrial. A rating of five refers to an option that can withstand large temperature ranges and a one to an option that must be protected.
Availability
Availability represents the approximate ease with which an option can be acquired on a long time scale. A rating of five means the option should be available for the foreseeable future from various vendors, while a one means limited availability or a small number of suppliers.
Client Preference
Client Preference represents the desires of the client, Sedona Energy Labs (SEL). In many parts of this project, SEL has expressed an interest in using a particular solution to the problem. A rating of five means the client has specifically noted this option, while a one is far from any situation they have envisioned.
Support
Support is a measure of how little support the option will require on the part of the client (SEL) and how much support the client receives from other sources (manufacturers, distributors, etc.). A rating of five represents a minimum amount of effort on the part of the client to support the option, while a one represents significant time or monetary requirements.
Development Cost
Development Cost represents the relative cost to develop the option. This category does not include the actual cost of the item (which is part of the Cost category above) but the non-recoverable engineering expenses. A rating of five means the option is cheap to develop, while a one is expensive.
Development Time
Development Time represents the time required to develop the option. A rating of five means the option is simple or straightforward to develop, while a one is complex and involved.
Decision Matrix
The three options above were rated in each category above. The matrix of scores and the composite scores can be seen in Table 1
| Category | Weight | Option | ||
|---|---|---|---|---|
| PLC | MCU | FPGA | ||
| Cost | 5 | 1 | 5 | 4 |
| Ease of Integration | 4 | 5 | 2 | 2 |
| Accuracy | 1 | 4 | 5 | 5 |
| Power | 5 | 3 | 5 | 4 |
| Durability | 4 | 5 | 3 | 2 |
| Availability | 3 | 5 | 5 | 5 |
| Client Preference | 5 | 5 | 4 | 2 |
| Support | 2 | 4 | 2 | 2 |
| Development Cost | 4 | 4 | 2 | 2 |
| Development Time | 5 | 4 | 2 | 3 |
| Composite Score | 148 | 132 | 113 | |
As can be seen from the matrix, the PLC was a slightly better option than the MCU, while both were significantly better options than the FPGA. Because of this, the final design selected will include a PLC as the system controller.
Environmental Sensors
There are two environmental conditions which the solar tracking system needs to respond to: wind speed and snow load. In both cases, the system needs to park the solar panels in a given orientation to reduce or eliminate the detrimental effects of that condition.
A high wind speed can cause an improperly aligned solar panel to oscillate or develop lift, placing excessive stress and strain on the panel frame. To alleviate this, the solar control system will periodically measure the wind speed and if that speed exceeds a given threshold, park the panels in a louvered position rather than to continue to track the sun.
To accomplish this, the system controller needs access to wind speed data. As the client specifically does not want the software to be designed for a specific model of sensor, the system will be designed to be compatible with any wind sensor having an analog output. For testing and design purposes, the system will be developed with the provided anemometer, a Davis anemometer (Model No. 7911).
Snow load can also cause undue stress on the frame if the snow is allowed to build up to a given depth on the solar panels. Again, to combat this, the system controller needs access to snow load data. Again, keeping the system manufacturer agnostic, the system will be designed to be compatible with a digital weather station with the ability to report the presence of snowfall. In this case, while the weather station reports snowfall, all panels will be periodically parked to drop the snow, then return to tracking the sun.
Orientation Sensing
Orientation sensing encompasses any sensors that relay the current panel orientation to the controller. This allows the controller to, based on the current panel orientation; engage the linear actuators until the desired azimuth and elevation angles are reached.
There are three viable options available to sense the orientation of the panels. They are as follows: dead-reckoning, rotary encoder, and inclinometer.
Dead-reckoning relies on a constant actuation per time interval, so that the distance the actuators move can be estimated by how long a voltage was applied. Although this offers an option with no additional hardware requirement, actuator drift might be encountered, causing the current actuator position to be unknown.
A rotary encoder connects to an axillary point in the tracker frame, and provides the current angular position of the axle. Although this provides a reliable method of determining the position of the panels, it requires significant mechanical modifications to the frame, and increases cost.
A two-axis inclinometer attached to the rear side of a panel would provide the orientation of the panels with respect to the Earth's center of mass, allowing for the tip and tilt to be determined.
Decision Matrix
| Category | Weight | Option | ||
|---|---|---|---|---|
| Dead-Reckoning | Rotary Encoder | Inclinometer | ||
| Cost | 3 | 5 | 1 | 2 |
| Ease of Integration | 4 | 3 | 1 | 4 |
| Accuracy | 5 | 1 | 5 | 4 |
| Power | 3 | 5 | 2 | 3 |
| Durability | 4 | 5 | 2 | 4 |
| Availability | 3 | 4 | 3 | 3 |
| Client Preference | 4 | 1 | 1 | 5 |
| Composite Score | 83 | 59 | 96 | |
It is recommended that a two-axis inclinometer be selected, as it offers a combination of easy integration with the existing hardware, and provides an accurate method of measuring the angle of the panels with relation to the Earth's center of gravity.
Sun Tracking Algorithm
The sun-tracking algorithm determines the current position of the sun, when provided with the current time, date, and geodetic location. There are two options that would result in the required output of the sun's azimuth and elevation: NREL MIDC's SOLPOS (National Renewable Energy Laboratory Measurement and Instrumentation Data Center's Solar Position and Intensity) algorithm and a custom algorithm.
NREL's SOLPOS algorithm is currently a built-in of the customer-suggested PLC. This allows for minimal development time, and offers a proven and reliable solar tracking algorithm.
A custom algorithm will require significant research, development, and testing time.
It is recommended that NREL's SOLPOS algorithm be implemented, assuming that the suggested Yokogawa PLC is utilized as the system controller. This would eliminate excess development time, and provide a proven method of locating the current position of the sun.
Backtracking Algorithm
The backtracking algorithm eliminates self-shading, which occurs when the frame or adjacent PV panels cast shadows onto the array, causing a significant decrease in power output. It is necessary and desirable to implement this feature to ensure that the panels will not be shaded by tracking or power generation hardware at any point during the day.
There is one option for implementing this function, which is to develop a custom algorithm that calculates the "safe" azimuth angle at which no shading will occur. Based on the current solar azimuth and altitude, it determines if this angle can be accomplished without shading, or if the safe azimuth angle must be used instead.
In order to determine the angles at which shading occurs, the PV panel size must be known by the controller; the larger the panel width, the sooner shading will occur from the frame onto the panels. The frame's dimensions are assumed fixed, and will be programmed into the controller before distribution to the user or installer. Once the hardware's dimensions are known, a set of trigonometric functions are executed to determine how the sunlight will fall onto the system, and if it will cast a shadow at the desired azimuth and elevation angles. Based on the output of these functions, backtracking may occur, resulting in utilizing the safe azimuth angle.
Actuators
The actuators that will receive the signals sent from the PLC and move the photovoltaic array are mechanical design elements. The choice of actuator is immaterial save for the requirement that it have an industry standard interface. This simply means that the actuator needs to have a positive and negative terminal. The precision of the actuator does not influence the function of the solar control system; dead-reckoning as a means of orientation sensing will not be employed.
Collision Detection
A desire of the solar controller is for the system to be intelligent enough to detect if an obstacle is preventing the array from moving, preferably before any damage is sustained by the obstacle.
Options
Current Sensing
Initially it was thought that a change in current draw from the actuators while attempting to move the array could be monitored to indicate a strain on these actuators, resulting from an obstacle blocking their movement. The power could then be cut before damage is done to the array or the obstacle. This option was researched and it was determined that this particular approach would be extremely difficult based on the low-current-draw-to-high-torque ratio of the actuators. This characteristic makes it unfeasible to detect an obstacle before damage is done.
Orientation Sensing
The second approach to this problem is to use any orientation sensor that can supply two analog outputs that monitor the tip and tilt of the array. Using this orientation sensor, the monitoring of the array location can provide feedback to the system if the desired position has not been reached. This solution is the most feasible as the program will need to track to position of the array to function correctly.
| Category | Weight | Option | ||
|---|---|---|---|---|
| Current Sensing | Orientation Sensing | |||
| Cost | 1 | 2 | 2 | |
| Ease of Integration | 4 | 3 | 4 | |
| Accuracy | 5 | 1 | 4 | |
| Power | 3 | 3 | 3 | |
| Durability | 4 | 3 | 3 | |
| Availability | 1 | 5 | 5 | |
| Client Preference | 5 | 1 | 5 | |
| Composite Score | 50 | 89 | ||
Installation Location
Using an algorithm based PLC controller, the longitude and latitude of the solar array must be known to track the sun accurately. Attaching any sensor that can monitor these variables is not cost effective because the array will not move once it is installed. Instead, the installer will use a sensor when installing the array to calculate the latitude and longitude of each array; this information will be input into the software for tracking the sun.
Power Source
The solar array and its control system will be installed at locations with utility power available for use. The power consumption of the programmable logic controller—which includes peripherals—is up to 5 watts. Since the PLC uses 24VDC, an AC-DC converter will be implemented at the site, chosen by Sedona Energy Labs. This is the extent of the power source design, since the system will not need to use the power produced from the solar array.
User Interface
A user interface is desired to interrupt the solar tracking system for repositioning the array for mechanical maintenance or other service. While connecting to the PLC with a laptop and proprietary USB connection cable is possible, it is not very practical since it requires carrying all the necessary equipment to the site each time maintenance is performed. Instead, a multi-button interface will be mounted with the system and programmed into the PLC operation. This multi-button panel will be convenient and will require five controls: one to switch from the PLC control to manual control, two for movement in either direction for the elevation axis, and two for movement in either direction for the azimuth axis.
Night Operation
When the sun travels too low on the horizon, the desired position for the solar panels at night is to have them louvered. There are many advantages to stowing the panels at night, such as reducing the panels' direct exposure to precipitation. This can prevent dirtying of the panel face or avoiding snow buildup altogether. The solar tracking algorithm will know when the sun is rising and the panels will move into the start-of-day position.
Design Revisions
Two major design revisions were made during the course of the project. First, the project proposal was accepted much later than originally planned. This compressed the schedule and required features to be dropped to compensate. This change marked a switch in the goal of the project from a marketable product to a proof-of-concept for the technology. As such, the ability to control multiple arrays at different orientations and the intelligent snow loading features were removed.
The multiple array feature was removed as it added significant testing complexity and additional hardware to the project while not solving any new problems. As a proof of concept it is merely necessary to prove that the sun tracking and control algorithms work on a single array.
The snow load feature was reduced from an intelligent reponse to some sort of snow sensor input, to a scheduled action. The proof of concept will move the panels to the most vertical position several times a day during winter months. This will dump off any snow accumulation. Again, as a proof of concept, the response to an external sensor can be ignored as this function is implimented in the wind load algorithm. It is merely necessary to prove that the panels can be moved on command to a snow dump position.
The second design revision was due to a change in the inclinometer selection. The inclinometer originally acquired for this project was found to be incompatible with the Yokogawa PLC due to differences in voltage signalling levels. As there was no time to acquire a new inclinometer, a desicion was made to use the built-in feedback of the actuators to sense the position of the array. At this time the selection of actuators was also changed. The new actuators had built-in collision protection and position feedback allowing the PLC to "tell" the actuators how far they should be extended rather than moving them until a feedback signal mached a desired value.