- 01What Is a Power Plant Controller?
- 02SEL RTAC Architecture — The Standard Design
- 03Animated Data Flow: RTAC ↔ Inverters ↔ Utility
- 04Volt-Var Control: Interactive Curve Builder
- 05Active Power Dispatch & Curtailment
- 06Default RTAC Configuration Reference
- 07PPC Platforms: RTAC, MOXA-based (N3uron, GPM, Solv, Draker, AlsoEnergy), Ignition
- 08Commissioning Checklist
01 — What Is a Power Plant Controller?
A Power Plant Controller (PPC) is the brain of a utility-scale solar plant. It sits between the utility SCADA master (which sends setpoints) and the field devices (inverters, revenue meter, switchgear) that execute them. Its job is to:
- Receive active and reactive power setpoints from the utility via DNP3
- Translate those setpoints into individual inverter commands via Modbus TCP
- Measure the point of interconnection (POI) voltage and current, and regulate Q to maintain a target voltage or power factor
- Execute Volt-Var, Watt-PF, or fixed power factor control modes
- Report site status back to the utility SCADA master
Without a PPC, each inverter operates independently. The utility has no way to dispatch the site as a single controllable resource. A PPC is required for CAISO, MISO, PJM, and most utility interconnect agreements on projects above 1 MW-AC.
The SEL RTAC (Real-Time Automation Controller, models 3530, 3355, or 3505) is the default choice on most North American utility-scale solar projects. It combines a DNP3 outstation, Modbus TCP master polling, AcSELerator RTAC logic programming, and IEEE 1547 ride-through support in a single hardened DIN-rail device. Everything described below assumes the RTAC sits between the inverters and the utility SCADA link.
02 — SEL RTAC Architecture — The Standard Design
The default RTAC PPC architecture connects three layers: the utility above, the RTAC in the middle, and the inverters below. Every setpoint flows down; every measurement flows up.
The RTAC operates as a DNP3 outstation toward the utility and a Modbus TCP master toward the inverters. This means it simultaneously speaks two different protocols in two different roles — a capability that simpler PLCs and most Modbus-only dataloggers cannot replicate without additional hardware.
03 — Animated Data Flow: Dispatch Sequence
Understanding the exact sequence of events in a reactive power dispatch cycle is critical for commissioning and troubleshooting. Here's the full loop — from utility setpoint to inverter response to POI measurement:
The Dispatch Loop (every 1–5 seconds)
- Utility master sends AO setpoint — DNP3 Analog Output (e.g., AO1 = 500 kVAR reactive injection) via DNP3 TCP to RTAC port 20000
- RTAC acknowledges — returns a DNP3 application confirm; updates the active setpoint register
- RTAC reads POI meter — Modbus TCP poll to revenue meter, reads AI registers: V_LL (kV), P (kW), Q (kVAR), PF
- RTAC calculates Q error —
Q_error = Q_setpoint - Q_measured; applies PI control loop - RTAC dispatches inverters — Modbus TCP write to each inverter: register 40212 (SunGrow) or register 40024 (SMA) with new Q setpoint
- Inverters respond — each inverter adjusts its reactive output; response time typically 100–500 ms
- RTAC reads new POI values — next poll confirms Q_measured ≈ Q_setpoint
- RTAC sends unsolicited DNP3 report — Class 2 AI values updated to utility master with new P, Q, V, PF at POI
A well-configured RTAC PPC completes this full dispatch loop in 1–3 seconds end-to-end. The biggest delays are Modbus poll time (20 inverters × 50ms/poll = 1 second) and inverter response time (100–500ms). The DNP3 leg to the utility typically adds <100ms on a LAN or <500ms on cellular.
04 — Volt-Var Control: Interactive Curve Builder
Volt-Var (VV) control adjusts reactive power output based on measured POI voltage. When voltage rises above nominal, the plant absorbs VARs (capacitive); when voltage drops, it injects VARs (inductive). The IEEE 1547-2018 default Volt-Var curve defines 4 voltage setpoints and 4 Q setpoints.
05 — Active Power Dispatch & Curtailment
Beyond reactive power, the RTAC PPC handles active power curtailment — reducing plant output on request from the utility or grid operator. The RTAC receives an AO setpoint (e.g., AO0 = 7500 kW = 75% of 10 MW rated) and distributes it proportionally across inverters.
Curtailment Distribution Logic
There are two common distribution strategies in AcSELerator RTAC logic:
- Equal distribution — divide the total setpoint equally: each inverter gets
P_setpoint / N_inverters. Simple but ignores individual inverter availability (e.g., one inverter in stow mode). - Proportional distribution — distribute based on each inverter's available capacity:
P_inv_i = P_setpoint × (P_rated_i / ΣP_rated_available). Handles partial outages correctly but requires reading each inverter's status register first.
If inverters are slow to respond to a large curtailment step (e.g., 100% → 30% in one command), the RTAC may issue additional curtailment commands before the first has taken effect, overshooting the target. Always implement a ramp rate limit in the RTAC logic and a deadband of ±2% before declaring the setpoint achieved.
06 — Default RTAC Configuration Reference
This is the baseline AcSELerator RTAC configuration for a 10 MW solar plant. Adjust IPs, port numbers, and Modbus register maps for your specific inverter make and model.
// One client definition per inverter IP address
// SMA STP 125-10 example register map
Client_Name = "INV_01_SMA"
IP_Address = "192.168.1.101"
TCP_Port = 502
Unit_ID = 3 // SMA default Modbus unit ID
Poll_Rate_ms = 1000
Timeout_ms = 500
Retry_Count = 3
// READ REGISTERS (Function Code 3)
REG_30001 = "P_actual_kW" // Active power output (0.001 kW/bit)
REG_30003 = "Q_actual_kVAR" // Reactive power (signed INT32)
REG_30775 = "Status_Word" // Inverter state (run/fault/stow)
REG_30201 = "DC_Voltage_V" // DC bus voltage (0.1 V/bit)
// WRITE REGISTERS (Function Code 16)
REG_40200 = "P_setpoint_pct" // Active power setpoint (% × 10)
REG_40208 = "Q_setpoint_kVAR" // Reactive setpoint (signed INT16)
REG_40210 = "PF_setpoint" // PF setpoint (×1000, e.g. 950 = 0.950)
Outstation_Address = 10 // Must match utility SCADA point config
Master_Address = 1 // Utility SCADA master DNP3 address
TCP_Port = 20000 // DNP3 default TCP port
Unsolicited_Enable = TRUE
Unsolicited_Class = 1 2 // Class 1 + 2 unsolicited
Integrity_Poll_s = 60 // Full integrity poll every 60 seconds
// BINARY INPUTS (to utility)
BI_00 = "POI_Breaker_52a" Class 1 // Trip event
BI_01 = "Site_Comm_Healthy" Class 1
BI_02 = "Remote_Control_Active" Class 2
// ANALOG INPUTS (to utility — POI measurements)
AI_00 = "P_POI_kW" DB=10 Class 2
AI_01 = "Q_POI_kVAR" DB=10 Class 2
AI_02 = "V_POI_kV" DB=0.1 Class 2
AI_03 = "PF_POI" DB=0.005 Class 2
// ANALOG OUTPUTS (from utility — setpoints)
AO_00 = "P_Setpoint_kW" // Active power curtailment — SBO required
AO_01 = "Q_Setpoint_kVAR" // Reactive power setpoint — SBO required
AO_02 = "PF_Setpoint" // Power factor target (signed, EEI)
07 — PPC Platforms: RTAC, MOXA-based, Ignition
The SEL RTAC is the default on utility-scale solar, but it is not the only option. The MOXA UC-8112 and UC-5000 series are the hardware base for several commercial PPC and monitoring platforms — N3uron, GreenPowerMonitor (GPM), Solv Engineering, Draker, and AlsoEnergy all run on MOXA boxes (or similar industrial Linux gateways) and provide their own PPC and SCADA layer on top. Ignition is usually the HMI sitting on top of the RTAC, not a PPC by itself.
The RTAC has a native HMI that you build in AcSELerator RTAC. It is not just a serial console. You can build full-color local screens with live POI values, setpoints, alarms, and operator controls without needing Ignition at all. On smaller plants the native RTAC HMI is enough on its own. On larger plants Ignition runs alongside it as the full SCADA layer, but the RTAC HMI stays as the panel-mounted local screen.
What's actually running on the MOXA UC-8112 / UC-5000
When you hear someone say "the PPC is a MOXA box," what they almost always mean is one of these:
| Platform | Runtime on the MOXA | What it does | Typical use case |
|---|---|---|---|
| N3uron | Node.js application, runs as a service on the MOXA Linux OS | Edge gateway with built-in DNP3, Modbus, MQTT, OPC-UA drivers. Tag-based architecture similar to Ignition but lighter weight. Has its own HMI module. | Multi-site fleets where one platform handles edge polling and central aggregation. Strong in EU and LATAM markets. |
| GreenPowerMonitor (GPM) | Proprietary Linux stack on MOXA hardware, often labeled as "GPM Plus" datalogger | Combined PPC, monitoring, and reporting. Modbus to inverters, DNP3 or proprietary to the GPM cloud, Volt-Var and active power dispatch onboard. | Large IPP fleets. Common on plants developed by European utilities and IPPs. Power BI-style reporting layer. |
| Solv Engineering | Custom Python/Node.js application on MOXA or industrial PC | Solv-branded PPC and performance analytics. Solv is owned by Power Factors. Strong on O&M analytics, not just control. | O&M-heavy contracts where the asset owner wants performance reporting bundled with the PPC. |
| Draker | Sentella platform (Linux-based) on MOXA-class hardware. Draker is now owned by AlsoEnergy / Stem. | Combined PPC + monitoring + revenue-grade metering. Volt-Var and curtailment built in. | Legacy installs from before the AlsoEnergy acquisition. Still common on plants built 2014–2020. |
| AlsoEnergy | PowerTrack platform — runs on AlsoEnergy datalogger hardware (often MOXA-based or AlsoEnergy-branded gateways) | Cloud-first monitoring with PPC capability. DNP3 to utility, Modbus to inverters. PowerTrack is the SaaS layer. | O&M-as-a-service contracts. Plant owner does not run their own SCADA; AlsoEnergy hosts everything. |
| Node-RED on MOXA | Open-source flow-based programming, Node.js runtime | DIY PPC built by integrators. Pull Modbus from inverters, run Volt-Var nodes, push DNP3 out via node-red-contrib-modbus and node-red-contrib-dnp3. |
Cost-sensitive C&I, community solar, or research plants. Not usually utility-approved without significant testing. |
The MOXA-based platforms (N3uron, GPM, Solv, Draker, AlsoEnergy) are mature products with real customer support. They are not "DIY scripts." What they cost you is flexibility. When the utility comes back with a new DNP3 point list requirement, or the inverter vendor changes a Modbus register, you are at the mercy of the platform vendor's release cycle. With an RTAC you change the AcSELerator project and re-download in 20 minutes.
Side-by-side comparison
SEL RTAC alone (with native HMI) — default for any utility interconnect. Utility engineers already know it, GridConnect library cuts ST coding, and the native RTAC HMI is enough for the local panel screen on plants under ~20 MW. Don't add Ignition until the plant actually needs full SCADA, alarming, and remote operator access.
MOXA-based platforms (N3uron, GPM, Solv, Draker, AlsoEnergy) — best when the asset owner wants monitoring + analytics + PPC bundled together, and is comfortable with the vendor controlling the release cycle. Strong fit for IPP fleets where one platform manages 50+ sites. Each vendor has different strengths: GPM and AlsoEnergy lead on monitoring + reporting, N3uron is more configurable, Solv leans into O&M analytics, Draker is mostly legacy.
RTAC + Ignition — use when the plant needs full SCADA on top of the PPC. The RTAC still owns the control logic (DNP3 outstation, Volt-Var, dispatch). Ignition is the visualization, alarming, historian, and remote operator console. This is the standard architecture on plants above ~50 MW.
The native RTAC HMI
One thing that gets missed in PPC discussions: the RTAC ships with a native HMI builder inside AcSELerator RTAC. You build screens in the same project as your ST logic, bind them to the live tag values, and download both at the same time. The HMI runs on the front of the RTAC chassis (3530-S models) or pushes to a web browser pointed at the RTAC's IP.
For a small or mid-sized plant the native HMI handles everything you need on the local panel: live POI values, setpoint operator controls, mode selection, alarm summary, breaker status, individual inverter status. The screens are not as polished as Ignition Perspective, but they do not need a separate server or a license either — they ship with the RTAC.
The pattern I use on bigger plants: native RTAC HMI for the panel-mounted local screen, Ignition for the control room and remote operations. Same RTAC tags feed both. The RTAC is the source of truth either way.
The GridConnect library deserves its own article. I wrote a full walkthrough covering the four function blocks, the six control modes, the assignment-operator trap that breaks the compiler, the Simple vs Advanced power limit math, capacitor sequencing, tuning defaults that need to change, and when to write custom ST instead.
The RTAC also participates in IEC 61850 GOOSE messaging for sub-cycle protection signaling — trip blocking, anti-islanding, breaker-fail backup. Different domain from PPC controls, same hardware.