My Solar SCADA Wish List: Basic Architecture

My Solar SCADA Wish List: Basic Architecture

By: Adam Baker

Better I&C to Improve Plant Performance Tracking.

I’ve never walked onto a solar site and thought, “Congratulations! It looks like you have the tools you need to really understand how well your plant is running.”

Unfortunately, I don’t have much of a say in the architecture of solar sites.

Over my 20 years working in solar instrumentation and controls, I’ve put together a little wish list of how I would build the I&C architecture if I developed and owned my own utility-scale solar plant. The idea is to build the best possible infrastructure on which to gather the data that would best help me understand and analyze plant performance.

Whether you’re building a new site, or looking for ideas to upgrade aspects of your existing site, these are my recommendations.

If I were to build a solar site, this is exactly how I’d do it.


Use the RTAC as Your Plant Controller

I am usually a supporter of PLC-based architecture (e.g., ControlLogix), and if you've already picked a platform, disregard this section. An RTAC (Real-Time Automation Controller) is a device manufactured by Schweitzer and often utilized in a large, transmission-connected solar plant as a data concentrator. RTACs are widely used in control houses and substations across the industry by the balancing authority to gather plant data.

The cool part about an RTAC that nobody realizes? It can double as a plant controller. For all practical purposes, an RTAC is a Programmable Logic Controller (PLC). It has the ability to do control functions and even limited visualization.

True, it’s less powerful than a high-end PLC, but for real time control, you don’t need it to be. Most PLCs in solar applications are underutilized and overqualified anyway. A one(ish) second response time is powerful enough for most utility-scale solar sites.

An industrial PLC delivers most value when a couple millisecond response is needed, such as grid voltage regulation at 250ms end to end response time. In this scenario, you may need to dedicate a RTAC for control, and require a second RTAC in order to adequately respond to all external requests, manage time sync for all devices, GPS time, etc. without becoming overtaxed.

Not to mention RTAC is a platform the industry is already comfortable with. The basic architecture and infrastructure already exists. On sites larger than 5MW, the cost of an RTAC is already built in the control house, so you’re effectively getting a free PLC.


Start Using PI Historian

OSI PI System is a widely-used historian in the energy industry, as well as other "big data" applications. On large sites that could cause grid instability, the utility uses this historian to store data such as irradiance, inverter status, plant output, and reactive power. If a piece of the transmission system trips offline and your solar system was affected, the utility investigates the outage by combing through the data collected in the historian as well as relay protection devices.

Because utilities already use PI historians, nearly everyone has connectivity to one. I recommend moving the data from your site PI historian to a corporate PI historian so you can also store and analyze your own data. (See also: Combine the Power of Historians and SQL Databases to Run a Solar Plant More Efficiently).

Why bother? Historians help you understand the root cause of problems by looking through conditions that could have preceded the incident. It also helps with performance analysis from year to year in similar weather situations.


For 5MW and Over, Use Fiber for Communications

Once installed, fiber optic makes for secure and reliable communications. For sites 5MW and over, fiber is almost always the best choice. If you’re already trenching for AC and DC to every inverter anyway, it doesn't cost much to drop fiber in at the same time.
For sites smaller than 5MW, there’s a strong case to be made for wireless communications. Wireless (like Weidmuller and Ubiquiti) is highly reliable when deployed appropriately, but when things break, it’s often due to something outside your control (like a RF noise-generating neighbor). Further, wireless has strong encryption capabilities, but can still be susceptible to hacking, whereas fiber is MUCH harder to hack.

Fiber optic’s strengths include:

  • Traveling long distances with little signal degradation
  • Near-infinite bandwidth and scalability
  • Immunity to electromagnetic interference and noise
  • Ring redundancy which allows for better network availability during maintenance


Use a Campbell Scientific Met Station to Unite Different Devices

Some off-the-shelf SCADA providers may have three or four separate interface devices to collect signals from met station instruments. Speaking from experience, managing 3 or 4 different devices is problematic.

I like the Campbell Scientific datalogger base met station, and here’s why:

  1. It can talk to any weather peripherals and internally convert signals into engineering units for easy implementation into SCADA
  2. If there’s ever a loss of network communications, it saves and logs data for retrieval later on
  3. It transmits via DMP or MODBUS TCP, and can even push periodically to FTP for asynchronous data collection
  4. Unlike most met stations, it has built-in control capabilities. For example, we programmed one to disable the pyranometer heaters and ventilators as soon as it starts running on battery power to maximize battery life.


Run Inverter Communications with Ethernet

Some string and central inverters still use MODBUS serial protocol. Use a protocol converter to reroute those to Ethernet to use just one communications path over a high-speed network.

Why? Cat5 (and the associated labor and O&M) is much less expensive than a shielded serial cable. Not to mention with a multi drop serial network, you have to pay attention to a lot of technical detail (which end to drain the shields, when and where to use a termination resistor, length limitations and addressing in multi-drop chains, etc.).

Many protocol converters are somewhat intelligent, and can be used as data concentrators so they’ll pull data from serial devices asynchronously from the Ethernet polling. When you pull with Ethernet, you get data from the gateway not waiting for propagation of serial communications.

Finally, troubleshooting tools like Wireshark are widely available, so Ethernet troubleshooting is a modern skill, and serial is much older technology. (I remember when there was a battle between Ethernet and Token Ring, and the best candidate won...) There’s a reason why you probably don't use a serial mouse with a 9-pin D-Shell connector any more. Newer, better technology exists.


Use Whatever HMI Software You Want. It Doesn’t Matter

There are a LOT of options for HMI / SCADA software today, and they're all pretty good. There isn't too much magic to solar that there's a clear advantage to one over another, so if you like InTouch, iFIX, Cimplicity, Factory Talk View, Ignition, WinCC, VT SCADA, Citect, or any of the other options, you'll be able to run the plant, see the data, set the set points, trend the trends, and do the things that need to be done.

That being said, all are configured a bit differently. I like saying the "the software best for the application is the software you know best". If you or your provider have experience with a specific platform, there is a strong advantage to using that platform from a supportability and cost standpoint. For example, if you are fluent in Cimplicity, but Ignition costs a lot less per license, your savings could EASILY be eaten up in learning how to use the new package, so don't let the cost be your primary driver.


Make These Changes to Increase Overall Plant Output

This basic architecture wish list isn’t outrageous. Implementing all of these recommendations can be done without exceeding industry norms for cost per MW. If everyone implemented this wish list at their solar site, I guarantee they would spend a lot less time implementing and troubleshooting, and a lot more time analyzing, and isn't that what monitoring systems are for?


Adam Baker - Affinity EnergyAdam Baker is Senior Sales Executive at Affinity Energy with responsibility for providing subject matter expertise in utility-scale solar plant controls, instrumentation, and data acquisition. With 23 years of experience in automation and control, Adam’s previous companies include Rockwell Automation (Allen-Bradley), First Solar, DEPCOM Power, and GE Fanuc Automation.

Adam was instrumental in the development and deployment of three of the largest PV solar power plants in the United States, including 550 MW Topaz Solar in California, 290 MW Agua Caliente Solar in Arizona, and 550 MW Desert Sunlight in the Mojave Desert.

After a 6-year stint in controls design and architecture for the PV solar market, Adam joined Affinity Energy in 2016 and returned to sales leadership, where he has spent most of his career. Adam has a B.S. in Electrical Engineering from the University of Massachusetts, and has been active in environmental and good food movements for several years.