Solar Plant SCADA System: Reference Architecture in One Diagram

A utility-scale PV plant’s SCADA is rarely “just a screen.” It’s a system-of-systems that has to move measurements and commands across devices, networks, controllers, servers, historians, and (often) a utility/ISO boundary—without losing meaning (units, scaling, timestamps, quality) along the way.

This guide is for owners/operators, developers, EPCs, commissioning leads, and SCADA/DAS engineers who want a clear solar plant SCADA system reference architecture they can use to scope work, spot missing boundaries, and demand the evidence that prevents COD from turning into months of cleanup.

The one-diagram reference architecture (devices → utility boundary)

Every plant differs by vendor stack and interconnection requirements, but most utility-scale PV sites map cleanly into five layers. Use the diagram below to align scope and responsibilities.

Solar Plant SCADA System – Reference Architecture (text diagram)

1) Field / Measurement Layer
Inverters • Tracker controllers • String/combiner monitoring • MET (POA/GHI, temps, wind) • Revenue/plant meters • Breakers/relays (substation/POI)

2) Communications / Network Layer (OT network)
Copper + fiber media • Managed switches • VLANs/subnets (if used) • Serial/Ethernet gateways • Remote access edge (router/firewall/cellular/carrier)

3) Control & Compute Layer
RTU/RTAC (utility-facing) • Power Plant Controller (PPC) / plant controller logic • Time sync (NTP/GPS) • SCADA servers • Historian/database • Engineering workstation/config backups

4) Presentation / Operations Layer
HMI screens • Alarm management • Trends • Reports/KPIs • User roles/audit (where required)

5) Utility / ISO Interface Layer
Telemetry + controls over DNP3 or IEC 60870-5-104 (typical) • Test/witness procedures • POI verification measurements

What each layer must do (and what “done” looks like)

1) Field / measurement layer: where truth starts

This layer produces the raw facts (power, energy, irradiance, breaker status) and accepts the physical actions (limits/setpoints) that change plant behavior. If this layer is wrong, everything upstream becomes a debate.

Revenue/POI metering: confirm CT/PT ratios, sign convention (import/export), and a reconciliation method against the meter display or test source.
MET and irradiance: confirm plane (POA vs GHI), orientation/level, and the scaling method (especially if sensors are mV or 4–20 mA into a datalogger/RTU).
Inverter & tracker points: confirm vendor register maps, firmware alignment, and what points are “operationally required” vs “nice to have.”

2) Network layer: the plant data highway

On utility-scale PV, the network is where small quality issues become big commissioning delays: intermittent drops, flat networks with noise, unmanaged switches, undocumented fiber routes, or unclear segmentation boundaries. SCADA can’t fix a network that is unstable.

Topology: star, ring, or hybrid—chosen intentionally based on failure domains and recovery expectations.
Managed switching: configuration saved, backed up, and mapped to a port plan so teams can isolate faults quickly.
Fiber baselines: if fiber is used, keep OTDR traces and insertion loss results (OLTS if required) organized by link ID so future troubleshooting is evidence-based.

3) Control & compute layer: where commands become plant behavior

Utility-scale solar typically uses an internal plant communications protocol (often Modbus) for device data and a utility-facing protocol (often DNP3 or IEC 60870-5-104) at the interconnection boundary. Many architectures bridge these using an RTU/RTAC and/or PPC logic.

RTU/RTAC: exposes the utility point list, handles secure/controlled command paths, and provides a clear demarcation for witness testing.
PPC (power plant controller): enforces active power limits, ramp rates, and reactive/PF/voltage modes required by the interconnection agreement.
Time synchronization: NTP (or GPS-based time) must be configured and verified so historian values line up with alarms and KPI windows.
Historian: stores the “record of truth” for operations and reporting—so mapping, units, and timestamp integrity matter as much as the HMI.

4) Presentation layer: make it usable for operators (not just installers)

Operators need fast answers: what’s down, where, and why. That requires an HMI that prioritizes actionable alarms and clear plant state—rather than showing everything equally.

Alarm strategy: priorities, deadbands, clear text, and notification rules. Poor alarm design creates “alarm floods” that train teams to ignore real problems.
Dashboards: show POI power/energy, curtailment state, PPC mode, comms health, and key availability drivers.
Role-based access: ensure setpoints/controls are guarded with clear permissions and change logging (especially during witness testing).

5) Utility/ISO interface: where COD pressure concentrates

At the utility boundary, the plant must prove telemetry correctness and control performance at the POI. This is where “online but wrong” values and incomplete command paths get exposed.

Telemetry: POI MW/MVAR, voltage, frequency, breaker status, plant/PPC status, and any additional points required by the utility.
Controls: active power setpoints and ramps, reactive/PF/voltage modes, and any required enable/disable behaviors (implementation varies).
Evidence: staged test reports with measured results at POI, plus rollback steps verified during the test.

The commissioning lens that prevents rework: Measurement, Meaning, Control

If you only remember one framework, use this. It keeps the team aligned and forces end-to-end proof instead of “it changes on the screen.”

Measurement: is the device reading/action correct (wiring, CT/PT, calibration, sensor orientation, device configuration)?
Meaning: do units, scaling, sign conventions, timestamps, and quality flags stay consistent through every boundary?
Control: when a setpoint/command is issued, does the plant respond as required at the defined boundary (typically POI), within tolerances?

Common architecture choices (and the trade-offs to decide early)

Decision	Why it matters	Typical trade-off
Flat network vs segmented (VLANs/subnets)	Limits broadcast/noise and reduces blast radius of failures	Segmentation improves resiliency but requires better documentation and switch discipline
Ring vs star topology	Defines failure domains and recovery expectations	Rings add complexity; star can create single points of failure
Modbus internally + DNP3/IEC 104 at boundary	Common pattern for PV device integration and utility telecontrol	Gateways add risk for scaling/word-order/sign mistakes unless point discipline is strong
PPC as a dedicated controller vs integrated in another platform	Impacts response time, test methods, and vendor boundaries	Fewer boxes vs clearer demarcations and easier acceptance testing

What to include in a commissioning-ready SCADA deliverables package

If you want to avoid late-stage integration scramble, contract for deliverables (evidence), not just “integration.” Start with the list below and tailor it to your interconnection agreement and owner standards.

Commissioning-ready point list: source device, address/register, data type, byte/word order, scaling math, units, expected ranges, scan rate, and quality rules.
Network as-builts: topology, IP plan, VLAN/subnet map (if used), and cabinet-to-cabinet connectivity.
Port maps + switch backups: managed switch configurations exported and labeled, with a port plan that matches cabinet labeling.
Time sync evidence: NTP configuration and verification results for servers/controllers/RTU/historian.
Fiber documentation (if fiber is used): route as-builts, splice matrices, labeling schedule, OTDR traces, and insertion loss results (where required).
Utility interface test package: telemetry mapping proof at the endpoint and staged control test reports with POI measurements and rollback steps.
Turnover package for O&M: final drawings, device inventory (models/serials/firmware), config backups, test evidence, and a “how to restore” runbook.

Failure modes this architecture diagram helps you catch

Use this section as a quick “what could go wrong?” checklist during design reviews and pre-witness testing.

“Online but wrong” values: wrong Modbus registers, wrong data types, swapped word order, or double scaling that only shows up in the historian/report layer.
Two truths: HMI looks right but historian/KPI values are wrong due to mapping, units, or timestamp alignment issues.
Intermittent comms gaps: fiber that passes light but drops packets; dirty connectors; marginal splices; undocumented switch configs; overloaded polling.
POI sign confusion: export/import definitions not aligned across meters, SCADA, and utility telemetry points.
Command path breaks: setpoints appear accepted in SCADA but PPC/RTU logic or plant state prevents real POI response during witness testing.

Where REIG fits: commissioning-ready SCADA + DAS integration

Renewable Energy Integration Group (REIG) supports utility-scale PV assets with end-to-end SCADA + DAS design, installation, commissioning, and ongoing support—integrating monitoring, controls, and communications (including fiber/optical services). The goal is simple: make plant data trustworthy from day one, reduce rework during commissioning, and deliver a turnover package O&M can actually use.

For teams that want standardized builds and faster handoff, REIG also supports commissioning-ready hardware/enclosures and configurations through RenergyWare.

Conclusion: a clean architecture diagram is only valuable if it’s backed by evidence

A solar plant SCADA system works when every boundary is owned and proven: device measurement truth, network stability, time sync, point-list meaning, and control performance verified at the POI. Use the reference architecture diagram to align scope early, then insist on commissioning evidence and documentation that keeps the plant reliable long after COD.

FAQ

What’s the difference between SCADA and DAS on a utility-scale solar plant?

A DAS (data acquisition system) focuses on monitoring: collecting, storing, and reporting measurements like irradiance, inverter data, and meters. SCADA includes data acquisition but adds supervisory control functions—such as plant-level setpoints and utility/ISO telemetry and control pathways. If the system must execute commands for grid compliance or plant dispatch, it effectively functions as SCADA.

Which protocols are most common in a solar plant SCADA system?

Many plants use Modbus (RTU or TCP) for device-level integration inside the plant network because it’s widely supported by inverters, meters, and weather stations. At the utility boundary, DNP3 and IEC 60870-5-104 are common SCADA telecontrol protocols. The key is not just the protocol choice, but documenting how points are mapped, scaled, and time-aligned end-to-end.

What are the most important signals to validate before utility witness testing?

Start with POI truth: MW/MVAR, voltage, frequency, and breaker/status points, validated against the meter or known-good references with correct sign conventions. Next, validate PPC/plant control states and the active power and reactive/PF/voltage control setpoints that will be tested. Finally, verify timestamps (NTP) and data quality flags so the utility sees stable telemetry and the team can defend results with evidence.

Why do we get “points on the HMI” but wrong values in the historian or reports?

Because communications only proves something is talking—it doesn’t prove meaning. Common causes include wrong registers, incorrect data types (16-bit vs 32-bit), swapped byte/word order, or scaling applied twice in different layers. The fix is an end-to-end validation method that checks the value at the device, at the gateway/RTU layer, in SCADA ingestion, and in the historian/report output.

What should be in a SCADA turnover package for long-term operations?

At minimum: final point list/tag dictionary with scaling and units, network as-builts with an IP plan, managed switch configuration backups, and device inventory including firmware versions. Include commissioning evidence for critical telemetry and controls (especially POI and utility points). If fiber is used, include route/splice documentation and baseline OTDR traces and loss results (as required) so troubleshooting later is fast and evidence-based.

References

Next step

Need a commissioning-ready SCADA + DAS architecture you can prove end-to-end (device → historian → POI → utility)? Share your point list, utility telemetry requirements, and commissioning schedule with Renewable Energy Integration Group (REIG). We’ll help you validate measurement, meaning, and control—including network and fiber baselines—so you hit COD with data O&M can trust.

Enter your keyword