Renewable Energy Software Development: Digitizing the Energy Transition

• Field data acquisition, data access rights, connectivity and market rules drive cost and schedule; dashboards and forecasting are downstream of all four.
• Only 13% of the capacity that entered US interconnection queues between 2000 and 2020 reached commercial operation, so the software has to survive attrition and long timelines.
• Ride-through performance (PRC-029-1) and FERC Order 2222 participation now carry compliance dates, which makes them feature specifications.
• The fastest way to evaluate a development partner is to ask what happens after the API call works.

In a typical product build, the specification is negotiable: an expensive feature gets cut or reshaped until the budget closes. In energy, the hard requirements come from outside. Field devices behave however their firmware dictates, and grid physics and market rules are just as indifferent to your budget.

The commercial environment is equally unforgiving. Berkeley Lab's Queued Up 2026 edition counts over 2,060 GW of generation and storage capacity waiting in US interconnection queues across roughly 8,200 projects. Of the capacity that requested interconnection between 2000 and 2020, only 13% had reached commercial operation by the end of 2025, and 75% was withdrawn; for projects that came online in 2025, the median wait exceeded five years.

Software scoped for this sector has to price that in: a platform can sit idle for years before the site energizes, and the portfolio it finally serves will not match the pitch deck.

Every architecture diagram starts with a box labeled "device data," and filling it is the line item teams most consistently underestimate. Utility-scale sites use a mix of Modbus, DNP3 (IEEE 1815), and OPC UA, and every inverter OEM implements its Modbus register map differently. SunSpec Modbus exists because that fragmentation was unmanageable: an open DER information model, referenced in IEEE 1547-2018 as a compliance path. Above the wire protocols sits IEC 61850, a semantic data model defining 808 standardized data objects and 115 functions for utility automation. It describes what a measurement means rather than how the bytes travel, and confusing it with a transport protocol is a reliable sign a vendor has never used it.

Milo's device-data experience comes from industrial energy rather than renewable generation: an Onan emissions and energy-management platform for offshore drilling rigs, integrated through Kongsberg K-IMS, the vendor monitoring layer in front of the equipment.

We did not communicate directly with PLCs over Modbus, OPC UA, or MQTT. Kongsberg K-IMS acted as the rig monitoring and integration layer, and we consumed its data through a REST API with rate limits.

We synchronized relatively low-level engine and equipment telemetry, stored a local copy, and transformed selected tags into values such as rig fuel consumption and emissions. The mappings and transformation formulas were configurable separately for each rig through an administrative UI, so the client's staff could configure or adjust a rig without Milo changing code or deploying anything. Once data access was available, adding a new rig from our side could take as little as 15 minutes.

The K-IMS documentation was generally useful, but it did not cover everything we encountered in production, so sometimes we had to inspect the actual responses and work things out ourselves. At one point, the API changed without notice, causing measured fuel consumption and emissions data to stop appearing until we identified and adapted to the change.

That 15-minute figure was the payoff of a design decision: the first integration carried the raw store and mapping configuration, plus the admin UI that later rigs reused. Budget the first vendor integration in weeks and every later one in hours, and treat documentation as a hypothesis to test against live responses.

The blocker nobody scopes for is contractual. Data coming off a turbine or an inverter passes through several hands, and each may control a piece of it:

• the asset owner, who assumes it is theirs
• the OEM, whose SCADA actually collects it
• the EPC that commissioned the site
• the O&M provider, whose service contract often defines who sees what

Teams tend to discover this weeks in, when the integration is ready, and the credentials are not, and no engineering resolves a contract. We hit a version of it on the rig platform, where approval set the onboarding timeline.

Access to K-IMS data was controlled by the client or rig operator and required approval. In practice, that external approval could take much longer than the technical configuration on our side, which could be done in around 15 minutes once access was available.

We therefore supported multiple ingestion paths. In addition to automatic K-IMS synchronization, clients can send fuel consumption data directly to our public REST API or enter it manually via the UI.

That meant we could first onboard a rig manually and later switch it to automatic telemetry once the necessary approvals were in place. It also allowed us to support rigs that were not using equipment covered by the K-IMS integration.

The design consequence generalizes: plan more than one ingestion path from the start, because manual entry and a public API stop looking like afterthoughts the day an approval stalls in legal.

Renewable sites sit where the resource is, which is rarely where the fiber is. Backhaul is cellular or satellite, and links drop. Hence, the software has to decide in advance what will keep working locally when the cloud disappears: anything that protects equipment or meets a grid obligation belongs on-site, while anything that only informs a human can wait. The harder engineering starts when the connection returns, because you have gaps to fill and duplicates to reject, and the upstream source may have revised its values in the meantime.

On the rig platform, we did not own the edge layer, but the synchronization followed the same physics.

We did not rely on a permanent live connection to the rig. A Celery job ran hourly and synchronized measurements incrementally, fetching data since the previous synchronization point.

We also built explicit recovery and reconciliation tools. If K-IMS data was missing, invalid or later corrected, an operator could refetch a selected historical period and choose either to fill only missing values or overwrite values that were already stored.

K-IMS was already the on-site monitoring layer in this project, so we did not build our own edge service on the rigs. Our responsibility was to make the synchronization recoverable and to ensure that temporary failures or corrected upstream data could be handled cleanly.

That separation paid off when the upstream API changed without notice: measured data stopped appearing while the rest of the platform kept running until we adapted. An external integration should fail without taking the product down.

The arithmetic escalates faster than intuition suggests. On the rig platform, we tracked only 10 to 12 relevant telemetry tags per rig at hourly resolution, which still meant roughly 87,600 to 105,120 source values per rig per year before refetches. A utility-scale solar site runs hundreds of inverters, each exposing dozens of registers, often sampled every second. Even with an across-the-board modest portfolio of billions of points a year, a naive relational schema stops answering queries long before the first anniversary.

Operating cost follows from retention and downsampling: how long raw data stays queryable at full resolution, and which aggregates are precomputed. We stored the raw source copy separately from the transformed values, which is what made reconciliation and auditing possible later, and I would repeat that choice at any scale. The storage design either makes the analytics layer possible or quietly rules it out, a pattern we cover in our guide to enterprise web development.

Vendor pages describe software that reads from the grid; increasingly the grid writes back, and the rules carry dates and penalties.

Curtailment and setpoint control are feature areas

CAISO curtailed 3.4 million MWh of solar and wind output in 2024, 29% more than in 2023, with solar accounting for 93% of the total, according to the US Energy Information Administration. Current-year numbers are available in CAISO's monthly renewables performance report; for the asset owner curtailment is lost revenue. For the software, the specification is to accept a reduced setpoint on command and record why, then quantify the production loss, because that number feeds settlement disputes and PPA reporting.

Ride-through is now a compliance obligation

Inverter-based resources have a documented record of dropping offline during grid disturbances: nearly 1,200 MW of solar lost in the 2016 Blue Cut Fire event, 2,555 MW in the June 2022 Odessa event, and 921 MW across nine solar facilities in southwest Utah in April 2023, all recorded in NERC's inverter-based resource reference guide. FERC Order No. 909, published in the Federal Register in July 2025 and effective August 28, 2025, approved reliability standard PRC-029-1, which makes voltage and frequency ride-through mandatory for inverter-based resources from October 1, 2026 under NERC's implementation plan. Settings management and disturbance evidence retention are now software problems with an enforcement mechanism behind them.

FERC Order 2222 sets your market roadmap

If the product aggregates distributed energy resources into wholesale markets, FERC Order No. 2222 is the governing rule. Aggregations as small as 100 kW can participate, and each RTO implements on its own schedule, published in FERC's Order 2222 explainer. The schedule decides which market you can enter and when.

"AI forecasting" on a vendor page tells you nothing until two questions are answered: what data goes in and how error is measured? The inputs are mostly public and free: NREL's National Solar Radiation Database provides satellite-derived irradiance (GHI, DNI, and DHI) at resolutions down to 5 minutes and 2 km, and NOAA's HRRR model delivers 3 km numerical weather prediction, updated hourly with radar assimilated every 15 minutes, out to 36 hours. The real engineering is the ingestion pipeline and the backtesting setup that scores every forecast against what the site produced.

The right model is sometimes plain arithmetic. The rig platform's forecasting was deterministic by design: we took a baseline from historical consumption, applied the expected effect of each planned reduction initiative, and compared the target against measured data as it arrived hourly. A target the client could audit served accountability better than a machine-learned one they could not inspect. Pick the model class after you know what question the forecast has to answer.

Whether the asset is NERC-registered is the first scoping question, because the answer changes the architecture. Assets on the bulk electric system fall under the NERC CIP reliability standards, which address network segmentation, remote access, patching, and logging. Retrofitting segmentation into a flat network is a rebuild, so ask the registration question before anyone draws the network diagram. At the small end, NIST IR 8498 provides seven practical cybersecurity guidelines for residential and light-commercial smart inverters, a sensible floor for DER products that will never undergo a NERC audit.

Every row below has stopped a sprint somewhere.

The test I apply to any renewable energy software development partner, including my own company, is whether they can tell you where their experience ends. Here is mine, as I would state it in a scoping call.

I can speak directly about a project: an emissions and energy-management platform for offshore drilling rigs. We worked with K-IMS telemetry, operational modes, fuel consumption and emissions calculations, historical baselines, and Emission Management Plans that compared expected reductions with those actually measured on the rig. That gives us direct experience with industrial telemetry and operational energy use. Still, I would not use this project to claim experience with renewable-generation controls, VPPs, battery dispatch, or direct PLC integrations over protocols such as Modbus or OPC UA. I also do not know Milo's other projects well enough to make broader claims on their behalf.

The admission tells you what a partner would be learning on the job, and the transferable core (telemetry ingestion, reconciliation, configurability) is what most of these builds depend on anyway. It also shapes what I tell clients about where scoping goes wrong.

What is often underestimated during scoping is everything that has to happen once the integration is running against real operational data. The calculations themselves can be difficult (they were in our case), but you also need to decide what happens when data is missing, corrected later, or temporarily unavailable; when access approvals take longer than expected; when the API is rate-limited; or when the vendor changes the API without notice.

The part clients tend not to scope properly is what happens after the API call works. In our case, we needed historical refetching, reconciliation, recovery after failed synchronization, and sufficient configurability for the client's own staff to add or adjust rigs without involving developers. Those things are easy to treat as edge cases at first, but they become part of the system's normal operation.

When turned into interview questions, it separates a partner who has operated one of these systems from one who has only read about them.

Weighing partners this way follows the same logic we use when choosing an MVP development company: evidence of handling specific failure modes beats the breadth of claims.

Keep one ordering from this piece: data acquisition, data rights, connectivity and compliance come first, and the dashboard and forecasting are downstream of all four. Scope in that order, and the impressive parts get built on something that stays up.

What is renewable energy software development?

It is custom software for renewable generation and storage operations, including monitoring, asset management, forecasting, market participation, and compliance tooling. It differs from standard application work because field devices, grid physics and market rules act as external specifications the build has to satisfy.

How long does it take to integrate a new device or site?

Once a data path and access rights are in place, configuration can take minutes; our record on an industrial telemetry platform was about 15 minutes per rig. The first integration takes weeks because it builds the tooling that later ones reuse, and access approvals often take longer than the engineering work.

Do we need to comply with FERC Order 2222?

Only if the product aggregates distributed energy resources into wholesale markets.

The compliance date depends on the RTO:

• CAISO is live now
• PJM's dates are February 2027 and February 2028
• MISO's are June 2027 and June 2029
• SPP arrives in 2030.

• US Energy Information Administration, Today in Energy: "Solar and wind power curtailments are increasing in California" (May 28, 2025). https://www.eia.gov/todayinenergy/detail.php?id=65364. Cited for CAISO 2024 curtailment: 3.4 million MWh, a 29% increase over 2023, solar 93% of the total.
• Lawrence Berkeley National Laboratory, "Queued Up: Characteristics of Power Plants Seeking Transmission Interconnection," 2026 edition. https://emp.lbl.gov/queues. Cited for 2,060+ GW in active queues across roughly 8,200 projects, the 13% completion and 75% withdrawal rates for 2000 to 2020 requests, and the five-year median timeline.
• PV Magazine USA, "Solar and storage to lead 86 GW capacity surge in 2026" (April 28, 2026). https://pv-magazine-usa.com/2026/04/28/solar-and-storage-to-lead-86-gw-capacity-surge-in-2026/. Cited for 2026 planned US capacity additions (86 GW total, 43.4 GW solar, 24 GW battery storage), reporting EIA Electric Power Monthly (April 2026) data.
• FERC, "Order No. 2222 Fact Sheet." https://www.ferc.gov/media/ferc-order-no-2222-fact-sheet. Cited for the order's scope and the 100 kW aggregation threshold.
• FERC, "FERC Order No. 2222 Explainer" (updated September 25, 2025). https://www.ferc.gov/ferc-order-no-2222-explainer-facilitating-participation-electricity-markets-distributed-energy. Cited for the per-RTO implementation dates in the table.
• Federal Register, "Reliability Standards for Frequency and Voltage Protection Settings and Ride-Through Requirements" (July 29, 2025). https://www.federalregister.gov/documents/2025/07/29/2025-14304/reliability-standards-for-frequency-and-voltage-protection-settings-and-ride-through-for. Cited for FERC Order No. 909, PRC-029-1, and the rule's August 28, 2025 effective date.
• NERC, "Implementation Plan: Reliability Standards PRC-024-4 and PRC-029-1" (September 2024). https://www.nerc.com/globalassets/standards/projects/2020-02/2020-02_prc-024-4_prc-029-1_implementation_plan_clean_09172024.pdf. Cited for the October 1, 2026 effective date of the PRC-029-1 ride-through requirements.
• NERC, "Inverter-Based Resource Activities Quick Reference Guide" (June 2023). https://www.nerc.com/globalassets/initiatives/inverter-based-resource-activities/ibr_quick_reference_guide_activities.pdf. Cited for the Blue Cut Fire, Odessa, and southwest Utah disturbance losses.
• NERC, CIP Reliability Standards. https://www.nerc.com/standards/reliability-standards/cip. Cited for the scope of mandatory cybersecurity controls on bulk electric system assets.
• IEC, IEC 61850 portal. https://iec61850.dvl.iec.ch/. Cited for the 808 standardized data objects and 115 functions, and the semantic data model framing.
• SunSpec Alliance, "SunSpec Modbus." https://sunspec.org/modbus/. Cited for the open information model and its IEEE 1547-2018 compliance-path status.
• IEEE, IEEE 1547-2018 standard page. https://standards.ieee.org/standard/1547-2018.html. Cited in the standards table for DER interconnection and interoperability.
• IEEE, IEEE 1815 (DNP3) standard page. https://standards.ieee.org/ieee/1815/6177/. Cited in the standards table for SCADA communications.
• IEEE, IEEE 2030.5-2023 standard page. https://standards.ieee.org/ieee/2030.5/11216/. Cited in the standards table for utility management of end-user energy.
• OpenADR Alliance, specification page. https://www.openadr.org/specification. Cited in the standards table for demand response signaling.
• Open Charge Alliance, Open Charge Point Protocol. https://openchargealliance.org/protocols/open-charge-point-protocol/. Cited in the standards table for EV charging communications.
• Green Button Alliance, Green Button / NAESB ESPI. https://www.greenbuttonalliance.org/green-button. Cited in the standards table for customer energy data exchange.
• NIST, "NIST Publishes NIST IR 8498: Cybersecurity for Smart Inverters" (December 2024). https://www.nist.gov/news-events/news/2024/12/nist-publishes-nist-ir-8498-cybersecurity-smart-inverters-guidelines. Cited for the seven guidelines for residential and light commercial smart inverter deployments.
• NREL, National Solar Radiation Database API documentation. https://developer.nrel.gov/docs/solar/nsrdb/. Cited for irradiance data types, resolutions, and free access.
• NOAA, High-Resolution Rapid Refresh (HRRR). https://rapidrefresh.noaa.gov/hrrr/. Cited for the 3 km resolution, hourly updates, 15-minute radar assimilation, and 36-hour horizon.
• CAISO, Monthly renewables performance report library. https://www.caiso.com/library/monthly-renewables-performance-report. Cited as the current source for CAISO curtailment reporting.

This article discusses regulatory and compliance topics, including FERC orders and NERC reliability standards, for general information only. It is not legal or compliance advice. Confirm current requirements and dates with your RTO, your counsel, or the relevant regulator before making commitments.