Local (onsite) SCADA systems for solar PV plants must often connect with third-party software as well as third parties like operations centers, ISOs and utilities. Successful integration is key to the stable and secure transfer of data. Let's take a look at connecting a local SCADA system to third-party software providers.
The SCADA system allows operators to monitor and control an entire solar PV plant from the Human Machine Interface. A local SCADA system is located onsite, as opposed to a remote operations center.
Most solar power plants have two types or levels of controls: the local plant level, and the operations center level. The operations center for a particular plant could be hundreds or thousands of miles away. If the operations center loses communication with the site due to a network outage or other issue, the local SCADA system provides a redundancy in controls. An operator or technician can go to the onsite SCADA computer and control the site from there.
Most solar power plants are vast, with miles of ground and thousands of devices. There are numerous other advantages of a local SCADA system:
SCADA software is powerful on its own, but the addition of third-party software can expand its capabilities. For example, asset management software like Power Factors Drive Pro streamlines operations and helps asset owners and O&M teams make data-informed decisions to improve plant performance. Third-party software uses data pulled in from the local SCADA system, hence the need for a successful connection.
In addition to asset management software, a local SCADA system may need to send and/or receive data from third parties. These may include a remote operations center, utility and/or ISO.
Our open architecture SCADA systems aren't constrained by software or hardware choices. We use Ignition or GE CIMPLICITY SCADA software as a standard bid on our jobs, but we aren't bound to that. We can adjust to use the SCADA software that best fits the customer's third-party connection requirements.
One of the reasons we use Ignition or CIMPLICITY is that both can serve data over OPC-UA. OPC-UA is an interoperability protocol that allows for secure Local Area Network (LAN) to Wide Area Network (WAN) connections. It is typically used to connect the local SCADA system to a third-party system, such as a cloud-based operations system or utility. OPC-UA has other advantages as well. You can check the quality of a particular data tag. You can also check the timestamp for when the data came through.
Again, though, Nor-Cal isn’t limited by one protocol. While we recommend OPC-UA, we are open to using Secured File Transfer Protocol (SFTP) or web API to provide local SCADA system data to third parties.
The three major protocols used for third-party connections are OPC-AU/DA, web API, and SFTP.
We can support other protocol options at Nor-Cal, including MQTT, RESTful APIs, and Kepware IoT. These require an additional licensing cost and more configuration, but we can provide data using these protocols.
First things first: you need a secure and stable internet connection at the plant. The data going back and forth between the local SCADA system and the third party demands a good internet connection and a reliable internet service provider (ISP).
Next: good network architecture between the plant and the third party. You need a secured connection. This is typically done using an IPsec VPN tunnel, though there are other acceptable methods.
Last: use the right protocol to send and receive data from the plant. Again, we typically recommend OPC-UA. If you need higher security, OPC-UA has features to handle that. Kepware IoT is another good secured option for data transfer.
All local SCADA systems, regardless of third-party connections, need a good server. We recommend Dell servers; the R340 is our preferred option. You also need a firewall for security to block unwanted traffic/attacks from the Web. We typically recommend Palo Alto 220 firewalls at the plant level. Palo Alto 820s are the best for security and recommended at the operations center level, but aren't typically needed at the plant level.
We recommend using SCADA software that can serve data using OPC-UA or web API protocol. It should also have the ability to use new protocols, which will give the system greater scalability as the plant and industry evolve. That's one of the key reasons we recommend Ignition SCADA software. It's modular, so you don't have to change the infrastructure or the software at the plant level if something changes in the industry.
However, while recommended, these software features aren't strictly required for third-party connectivity.
Eighty to ninety percent of the time, there is no significant effort required to implement third-party connections. It depends on two factors: the protocol used and whether or not there has been past interaction between the two parties (i.e., the plant and the operations center).
As stated earlier, OPC-UA and web API are designed for third-party connectivity. When they are built into the SCADA software, it's reasonably easy to implement third-party connections. SFTP or IoT push protocols require additional time and troubleshooting.
If there has been past interaction between the plant and the third party, there is less effort required on the third-party end to understand the plant data and structure. As the SCADA integrator, we help with this process. We provide an updated points list, which tells how many data points will be pulled from the site.
We are confident to incorporate any third-party software or protocol, and can find and implement solutions to meet your site requirements. Our open architecture local SCADA systems are bolt-on compatible, flexible and scalable. Request a proposal or schedule a call today.