SCADA Software for Solar and Renewable Energy
Inverters, trackers, substations and a grid operator on the other end, supervised as one system.
Request an Evaluation See the RFP checklist, answeredFrameworX is a SCADA and telemetry platform used in solar and renewable generation to supervise inverters, trackers, combiner boxes, meteorological stations, metering and substations across a fleet of sites. It collects from field devices over Modbus and publishes to a grid or remote operations centre over DNP3, acting as a protocol gateway between the two, with a store-and-forward historian so a site's record survives a communications outage. New sites are added to a running system without downtime. Local tags are unlimited in every edition, and more than 100 connectors are included in the license.
A solar plant is a fleet problem before it is a plant problem
A utility-scale solar operator does not run one plant. It runs a portfolio: several sites, often built years apart by different EPCs, each with its own inverter brand, its own tracker controller and its own substation. The sites are unstaffed. The people who look after them sit in one operations centre, and what they need is for twelve sites to behave like one system rather than twelve.
That is a different shape of problem from a factory. There is no single process to control, and the plant controller that curtails output or holds a power factor is usually already there, supplied with the plant. What is missing is the layer above: something that reaches every device at every site, keeps a complete record when a link drops, presents the fleet on one screen, and speaks the protocol the grid operator expects on the other side.
The hard part is rarely the first site. It is the eleventh, and whether adding it means taking the other ten offline.
Renewable portfolios grow by acquisition and by phase. A supervisory architecture that requires a maintenance window to add a site is a tax on every expansion, and for an operator with grid obligations a maintenance window is not always available at all.
What FrameworX does for a renewable operator
Every device at every site, over the links you have
FrameworX polls inverters, tracker controllers, combiner boxes, meteorological stations, revenue and check metering and substation equipment, over Ethernet, cellular, licensed radio and fibre. The polling rate is set per device rather than globally, so a fast local network and a slow backhaul coexist in the same project. Each node carries a primary and a backup station with a configurable failover timeout.
A protocol gateway between the plant and the grid
Field devices speak Modbus. Control centres speak DNP3. FrameworX supports both natively, as master and as slave, and translates between them, so the mapping from inverter registers to the points a remote operations centre expects is configuration rather than custom middleware somebody has to maintain and document.
Adding a site without taking the fleet down
The DataHub TagProvider lets a central system consume the tags of an edge site as if they were local, which means a new site is hot-added to a running system. There is no downtime for expansion and no rebuild of the central project each time the portfolio grows. Alarms and storage centralise, while local values stay at the edge and are inspected on demand rather than replicated upward, so adding a site does not multiply the traffic to the centre.
How a distributed FrameworX system is put together.A complete record after an outage
The historian stores and forwards. When a site loses its link, collection continues locally and the archive is backfilled when the connection returns. For availability and performance reporting, where a missing interval is indistinguishable from downtime, the gap is the whole problem.
Availability, performance and the reports they feed
Production, irradiance, expected against actual, inverter availability and curtailment are historised and calculated in the platform, with C#, VB.NET and Python 3 running natively in the runtime. Scheduled and on-demand reports in PDF, CSV and XML draw on the historian and on operator-entered values, which is how monthly availability and performance ratio reporting is usually assembled.
Alarms that reach whoever is on call
Alarm items, groups and areas, with acknowledgement workflows, shelving and a full audit trail, and notification by email and text message. An operations centre covering a fleet needs alarms grouped by site and by equipment class rather than one flat list, which is what areas and groups are for.
One project, operations centre to field
The operations centre, a laptop at the site and a phone in the field see the same application. The HTML5 client runs in a browser with no installation, and map-based views including ESRI put a geographically spread portfolio on one screen.
Unlimited local tags
Local tags are unlimited in every edition. The paid scaling axis is external I/O points, meaning the physical signals coming from the field, so modelling a string, a combiner or a calculated performance figure costs nothing.
Connectivity for renewable generation
A renewable site is assembled from equipment chosen by whoever built it, and a platform that only speaks to one vendor's inverters is not usable across a portfolio.
FrameworX includes more than 100 native connectors. The ones this sector reaches for:
- Modbus TCP and RTU, the common language of inverters, trackers, combiners, meters and met stations, including serial over radio
- DNP3, master and slave, for substation equipment and for reporting to a grid or remote operations centre
- OPC UA, client and server
- MQTT and Sparkplug B, both directions, with a built-in broker, for bandwidth-efficient reporting from remote sites
- Allen-Bradley, Siemens S7, Schneider, Beckhoff, CODESYS and Omron controllers, where a site uses one
- SNMP, for the network equipment that a distributed site depends on
- Historians and databases, native to the platform, with time-series options including PostgreSQL with TimescaleDB, plus connectors for external historians
- Cloud endpoints including Microsoft Azure and AWS IoT Core, for portfolio analytics
Connectors are included in the license rather than sold per protocol. For a complete utility SCADA product, Tatsoft's partner SPIN builds Action.NET on FrameworX for generation, transmission and distribution, with more than 400 systems deployed. The partner solution is described here.
The RFP checklist, answered
What a renewable operator should require of a supervisory platform, and where FrameworX stands on each line.
| What a renewable RFP asks for | FrameworX |
|---|---|
| Multi-vendor inverter and tracker collection | Modbus TCP and RTU native, with per-device polling rates |
| Substation and grid integration | DDNP3 master and slave, plus IEC 61850 and IEC 60870-5, with translation from Modbus |
| Protocol gateway between field and control centre | Bidirectional Modbus to DNP3 translation as configuration, no custom middleware |
| Meteorological station and irradiance data | Collected, historised and used in calculations like any other value |
| Revenue and check metering | Collected over Modbus or DNP3, historised and reported |
| Redundant SCADA servers | Full-project redundancy with automatic failover, licensed as an option |
| Store-and-forward at unstaffed sites | Built into the historian, with automatic resync on reconnection |
| Independent site operation during a network outage | Edge nodes keep collecting, alarming and logging locally |
| Add a new site without downtime | DataHub TagProvider hot-adds an edge site to a running central system |
| Historian with configurable retention | Built in, with PostgreSQL and TimescaleDB among the supported stores |
| Availability and performance calculations | C#, VB.NET and Python 3 native in the runtime, historised alongside measured values |
| Availability and production reporting | Scheduled and on-demand reports in PDF, CSV and XML |
| Alarm management, grouping and shelving | Items, groups and areas, acknowledgement workflows, shelving, full audit trail |
| Alarm notification to on-call staff | Email and text message built in |
| Web and mobile operator access | HTML5 client, zero install, desktop and mobile |
| Portfolio view across sites | Map displays including ESRI, with site status and alarms |
| Role-based security and audit trails | Role-based access control, secrets vault, full operator audit trail |
| Separation between plant and corporate networks | Application Gateway across the DMZ, single controlled path, no per-application firewall exceptions |
| Critical-infrastructure cybersecurity controls | Role-based access, TLS, secure gateway, secrets vault, audit trail, and published hardening and standards-compliance guides |
| NERC CIP | Compliance is assessed for the installed solution, not for a software product. Applications built on FrameworX have been validated under NERC CIP in production. The platform supplies the technical controls and the configuration guides |
| Plant control, curtailment and power factor | Control stays in the plant controller and the inverters. FrameworX is the supervisory and gateway layer, not the plant control loop |
| Backup, restore and disaster recovery | Project export and import, and Git-friendly JSON for version control |
| No internet dependency for site operation | Sites run on premises. Cloud and remote access are optional |
| Unlimited tags for modelling a fleet | Local tags unlimited in every edition. External I/O points are the paid axis |
In production
Solar and hydro generation, five substations, 250,000 points
A utility running solar and hydro generation needed a gateway between the field and its remote operations centre across five substations. The legacy system could not translate protocols at that scale, had no redundancy, and required full downtime for any change, which for critical grid operations meant that routine maintenance carried real risk.
The architecture puts FrameworX EdgeConnect at each of the five sites, collecting roughly 25,000 tags per site over Modbus from field devices including inverters and trackers, with store-and-forward and independent operation during a network outage. A central FrameworX Enterprise system carries the interface, the historian on PostgreSQL with TimescaleDB, the centralised alarm database, and the DataHub TagProvider that ties the edge sites to it.
In total the gateway handles 250,000 points, 125,000 Modbus reads translated to 125,000 DNP3 writes, in real time and with full-project redundancy, on 48 vCPU and 128 GB of RAM including the redundant pair. New edge sites are hot-added through the TagProvider without interrupting the running system.
Customer not named. The full architecture is documented publicly here.
The number worth reading twice
Two hundred and fifty thousand points with full redundancy runs on 48 vCPU and 128 GB of RAM. The reason that matters to a renewable operator is not the hardware bill. It is that a supervisory layer sized like this can sit at the operations centre of a growing portfolio without being re-architected every time a phase is commissioned.
Distributed generation and energy centres
FrameworX is deployed across plant energy centres, solar farms and substations, with substation integration, grid modernisation and renewable integration among the common applications. The energy and utilities documentation lists the capabilities in detail.
SCADA for electrical utilities, through a partner
Action.NET by SPIN is a SCADA product for the energy market built on FrameworX and sold under SPIN's own brand, with more than 400 systems deployed in substations and in generation, transmission and distribution. Read about the partner solution.
AI, and what it actually does here
FrameworX is AI-Native by architecture. Model Context Protocol servers for the Designer, the Console and the Runtime, all released and supported today, connect an AI model of your choosing to the live engineering project, so an engineer can describe a screen, a report or an alarm set and have it built, reviewing and approving every change before it runs. Across a fleet where every site is a variation on the same template, that is where the engineering hours actually go.
The model runs where you decide. FrameworX ships no model. It connects over an OpenAI-compatible endpoint to a model you run, on a separate networked machine of your own, or to a hosted one. The model host is deliberately not the FrameworX server: the two are separate machines, which keeps model workload off the supervisory server and keeps the boundary between them explicit. Once the model is on that host it needs no internet connection, so an operator who will not send generation data outside its own network can run the whole thing inside it.
Statistical models are not placed in the control loop. Curtailment, power factor and plant control stay where they are, in the plant controller and the inverters.
Common questions
What does SCADA do at a solar plant?
Solar SCADA collects data from the equipment across a plant, inverters, tracker controllers, combiner boxes, meteorological stations, metering and substation devices, and presents it as one system. It raises alarms on abnormal conditions, historises production and irradiance for availability and performance reporting, and passes the points a grid or remote operations centre requires to that centre in the protocol it expects. It is the supervisory and reporting layer above the plant, and it is typically where an operator sees every site in a portfolio at the same time.
How does solar SCADA scale across many sites?
The scaling question in renewables is rarely the size of one site, it is what happens when the eleventh is added. FrameworX uses a DataHub TagProvider so a central system consumes an edge site's tags as if they were local, which lets a new site be hot-added to a running system without downtime and without rebuilding the central project. Alarms and long-term storage centralise, while local values stay at the edge and are inspected on demand rather than replicated upward, so growth in the portfolio does not multiply traffic to the operations centre. A production deployment runs five sites at roughly 25,000 tags each on this pattern.
Which protocols does a solar or renewable plant need?
Almost always Modbus TCP and RTU, because inverters, trackers, combiners, meters and meteorological stations overwhelmingly speak it. On the grid side the requirement is usually DNP3, for substation equipment and for reporting to a remote operations centre. OPC UA is common where the site includes a PLC or another vendor's system, and MQTT with Sparkplug B is used where the backhaul is metered or slow. FrameworX includes all of these natively, along with more than 100 connectors in the license rather than sold per protocol. Where the site includes a substation, the utility side also asks for IEC 61850 and IEC 60870-5. FrameworX supports both.
Can SCADA act as a protocol gateway between the plant and the grid operator?
Yes, and in renewables it is one of the most common reasons to deploy one. Field devices speak Modbus and control centres speak DNP3, so something has to translate, and the alternative to a platform that does it natively is custom middleware that has to be written, documented and maintained. FrameworX supports both protocols as master and slave and translates between them as configuration. A production deployment runs 125,000 Modbus reads translated to 125,000 DNP3 writes across five substations, 250,000 points in total, with full redundancy.
Is FrameworX a power plant controller?
No. FrameworX is the supervisory, gateway and reporting layer. Active power curtailment, reactive power and power factor regulation and the fast closed-loop control behind them stay in the plant controller and the inverters, which is where the response times and the grid-code certification live. What FrameworX does is supervise that equipment, collect and historise what it reports, alarm on it, present the fleet, and exchange the required points with the grid or remote operations centre. Treating the supervisory layer and the plant controller as one product is a common source of confusion in solar RFPs, and separating them is usually what makes both easier to specify.
How is availability and performance reporting handled?
Production, irradiance, expected against actual output, inverter availability and curtailment are historised, and the calculations that turn them into availability and performance figures run natively in the runtime in C#, VB.NET or Python 3, so results are stored and trended alongside the measured values rather than assembled in a spreadsheet afterwards. Scheduled and on-demand reports are produced in PDF, CSV and XML from the historian and from operator-entered values. Because the historian stores and forwards, a communications outage does not leave a gap that later reads as unavailability.
Can a new site be added without taking the system down?
Yes. The DataHub TagProvider enables distributed engineering, where a new edge node is hot-added to the running central system rather than requiring a maintenance window. For an operator whose portfolio grows by phase and by acquisition, and whose grid obligations make maintenance windows scarce, that is usually a procurement requirement rather than a convenience.
Does FrameworX run on premises without an internet connection?
Yes. Sites and the central system run on premises. Cloud connectivity and remote access are optional rather than assumed, and where AI features are used the model runs on a host you control, which needs no internet connection once it is in place. Generation data does not have to leave the operator's own network for the system to work.
How is solar SCADA licensed, and what drives the cost?
FrameworX licenses are perpetual. Every module, feature and all 100+ connectors are included in each license, so there is no separate protocol, historian or reporting module to budget for. Local tags are unlimited in every edition, and the axis that scales the cost is external I/O points, meaning the physical signals coming from the field rather than the number of tag names in the project. EdgeConnect is the edge-specific edition, from $750. Annual support and maintenance is 20 percent, or 16 percent on a three-year term and 14 percent on a five-year term. Full-project redundancy is a licensed option that adds 50 percent.