One platform connecting fleet monitoring, performance intelligence, operational workflows, and compliance — built on a data path that stays correct when the link drops.
POWERED BY ENERGY COMPLIANCE, INC.
Renewable operations are becoming more complex faster than the tooling around them. Most fleets run monitoring in one system, performance reporting in another, and compliance evidence in a folder somebody maintains by hand. RenewOps puts all three on one record — so the number in a board deck and the number in an audit response came from the same place.
Fleet dashboard, geographic fleet map, and site detail down to the single-line — contracted MW, sites online, active alarms, inverters in fault, state of charge, and operator response time in one view.
Alarm trends by site, by asset and by type. Curtailment tracking. Recurrence patterns that turn a hunch about an underperforming string into an evidenced maintenance decision.
Actionable alarm tables with site, asset, code and message. Grid compliance monitoring with live band status and sample counts. Monthly O&M reporting exported as a finished document.
Suites are made of modules. A customer licenses suites; the modules are what they get. Core is always on. Everything below it sits inside a suite or licenses on its own, and licensing the parent suite includes its modules at no extra charge.
Where RenewOps stops. The platform produces the record and the evidence — the measurement, the band status, the ride-through capture, the position going into a window. It does not prepare NERC submittals, write RSAW narratives or build your compliance calendar. That is regulatory work performed by people who sign their name to it, and it is what Energy Compliance, Inc. does. RenewOps gives the filing its evidence. The firm writes the filing.
None of the above is worth anything if the underlying series has holes in it. Steady state is easy — the failure that costs you is the recovery, when a gateway holding seventy-two hours of history reconnects and flushes it in whatever order the queue drains, interleaved with live data, sometimes re-sent on retry. We force that condition on purpose, before cutover, and we don't certify a path that fails it.
Any failure means not certified. A green run against the live production instance is the cutover gate — not a validated reference, not a demo, the actual endpoint for that site.
Correctness comes from a primary key on identity — not from application logic that has to remember to be careful.
ts from the source, never arrivalON CONFLICT(identity) DO UPDATElast-write-wins on existing keyMetric, source timestamp, value, quality — keyed on (site_id, metric, ts).
A lifecycle, not a point. One alarm instance raises Active, optional Acknowledge, and Clear — each its own transition, keyed on (site_id, eventid, eventtype, eventtime). Field set conformed to the alarm journal your gateway already emits, so it maps one-to-one.
Store-and-forward lives on the SCADA gateway you already run. Replacing a legacy aggregator is a destination swap — not a rebuild of your buffering tier, and not another appliance in the rack.
SCADA gateway — store-and-forward, MQTT
Outbound only
Your perimeter, your rules
Fleet record, keyed on identity
The ingest endpoint stands up and gets proved with no gateway changes and no hardware. It can be deleted with zero blast radius. Nothing about your existing path changes until a shadow test passes on the live instance.
Audible alarms, the alarm journal, and the compliance record live on your SCADA, at the operator. A cloud monitor on the far side of a buffer cannot be your real-time alarm surface, and we won't pretend otherwise.
Moving off a legacy source that already fed the platform? The identity key lets old and new overlap during cutover — an overlapping record upserts instead of duplicating.
One proven pattern parameterized by site. Standardize the tag and alarm model once in your gateway's type definitions and every site inherits it — scale the fleet without re-deriving the path each time.
Five sites or fewer on one suite is a single published number, hosting and deployment included — nothing to scope, nothing to negotiate. Above that, four charges with four reasons. The licence is what the platform does, and it never changes with site count. Deployment is the one-time work of getting your fleet in — mostly ingesting and classifying alarm lists, which is why it bands with sites. Hosting is where it runs and who operates it. Services are people's time. Published pricing starts at $12k/year.
One week. We look at the data path you're running today and tell you whether it survives a link outage — before you license anything, and without touching your network.
The replay test is deterministic and runs against a reference instance parameterized by your site. That's how we can do it in a week — because it was designed not to need your perimeter.
It answers whether you need us before you buy us. If the answer is that your path is already sound, that's the finding, and you'll have it in writing.
We start with the path you're running today — what's buffering, what the flush does on reconnect, and whether anyone has ever tested it under an outage.