Solar SCADA / PPC – control boundary

Solar SCADA/PPC with the control boundary in view.

A Solar SCADA/PPC project defines what the plant can observe, what it may authorise and how the result is tested and handed over. Devices, protocols, command authority, response targets and utility requirements remain subject to project validation.

The useful question is which system is authoritative for each command, under which limit, with which fallback and evidence.

Observe / authorise / hand over01 / 02
Solar plant control and feedback boundaryPlant measurements from meters and plant values enter SCADA and PPC. A supervisory target such as a schedule or setpoint request also enters the authorised path. Measurement feedback returns from plant devices, while an authorised command moves to plant devices. OEM limits and protection remain an explicit boundary, with FAT, SAT and handover evidence shown separately.INPUT SIGNALSPLANT RESPONSEPlant measurementsmeters / plant valuesSupervisory targetschedule / setpoint requestInverters &plant deviceslocal executionOEM limits /protectionFAT / SAT /handover evidenceSCADA + PPCauthorised pathscope – limits – fallback
Illustrative control boundary only; final ownership, limits, interlocks, fallback states and acceptance evidence are confirmed per project.

How to read it: blue telemetry enters SCADA/PPC; lime target enters the control logic, then the authorised lime command leaves SCADA/PPC for the plant devices.

authorised commandmeasurement feedbackboundary / evidence
Monitoring boundaryAgreed signals, alarms, timestamps and operating states for the named plant.
Authorised controlCommand authority, interlocks, limits, manual override and fallback states.
Handover evidenceFAT, SAT, defect closure and as-built evidence tied to the approved scope.
The control question

SCADA shows the plant. PPC coordinates plant-level behaviour.

They can share data and interfaces, but they do not automatically own the same decision. Clear boundaries reduce commissioning ambiguity.

01 / SCADA

Observe

Acquire, normalise, visualise, alarm, store and report agreed plant data.

02 / PPC

Authorise

Coordinate plant-level active/reactive power, voltage, power factor, ramp or curtailment where configured.

03 / EMS

Arbitrate

Keep schedules, reserves, SoC windows and dispatch decisions explicit for storage or hybrid modes.

04 / OEM

Protect

Keep PCS, BMS, inverter and protection systems authoritative for local limits and inner control loops.

Design to handover

Turn a control idea into a testable project boundary.

Each stage should leave a decision record that the next stage can use. The exact deliverables depend on the contract, plant and utility interface.

  • 1
    Frame the plantConfirm topology, PCC, equipment, OEM documents, signal list, operating modes and utility requirements.
  • 2
    Map authorityAssign command ownership, permissives, limits, interlocks, manual override and local protection priority.
  • 3
    Validate the pathDefine test conditions, response measurement, fallback behaviour, FAT/SAT evidence and defect closure.
Control path02 / 02
PCC dataand modesSCADA + PPCauthorised pathPlantdevicesOEM limitsFAT / SAT
Where this approach is useful

Use the control boundary to make the next decision clearer.

The same SCADA/PPC questions appear at different project stages, but the evidence and authority required will change with the plant and contract.

01 / NEW PLANT

Define the plant-control architecture

Set the PCC, equipment, signal list, command ownership, operating modes, interlocks and utility interface before commissioning assumptions become fixed.

02 / RETROFIT

Assess an existing setup

Check OEM model, firmware, protocol functions, read/write scope, network path and tested behaviour before adding an overlay or changing authority.

03 / GRID INTERFACE

Clarify plant-level response

Map active/reactive power, voltage, power factor, ramp, curtailment or zero-export requirements to the responsible system and test method.

04 / ACCEPTANCE

Prepare commissioning evidence

Connect FAT, SAT, response measurement, fallback checks, defect closure, retests and the as-built record to the approved project scope.

Inputs before a workshop

Bring the source documents, not just the desired outcome.

These inputs help the technical review distinguish an available interface, a configurable path and an unresolved project question.

01 / PLANT

Topology and signals

Plant single-line diagram, asset list, PCC, signal list with source, destination, unit, quality state and timestamp requirement, plus operating modes.

02 / INTERFACE

Equipment and authority

Controller, inverter, meter, PCS/BMS and communications details; protocols, firmware, network path, read/write authority, permissives, interlocks and manual override.

03 / ASSURANCE

Requirements and acceptance

Utility, tender, grid-interface and cybersecurity requirements, test ownership, evidence format, defect process, retest method, support scope and handover location.

For Indian projects, review applicable requirements against the official CERC material and named state-utility documents. This page does not determine legal applicability or guarantee compliance.

Responsibility matrix

Make every command path answerable.

SCADA, PPC, EMS and local equipment may exchange information, but each must retain a defined responsibility for the named project.

SCADA / RMS

Observe and evidence

Acquire agreed signals, display states, alarm and report within the project-defined monitoring boundary. Review the SCADA/RMS layer for the visibility job.

PPC

Coordinate authorised control

Issue or coordinate plant-level commands only within approved authority, limits, permissives, interlocks and fallback states.

EMS

Schedule and arbitrate

Keep schedules, reserves, SoC windows and hybrid dispatch decisions explicit rather than treating storage optimisation as an automatic PPC function. See the EMS solution for the broader storage and hybrid coordination boundary.

PCS / BMS / OEM

Protect local limits

Retain local inner-loop control, equipment constraints and protection authority. Related edge integration can be assessed through Synapse Edge subject to project validation.

Buyer questions

Good control design leaves fewer assumptions hidden.

What should a Solar SCADA/PPC project scope define?

Define the plant topology, signals, point list, protocols, command authority, operating modes, interlocks, response measurement, fallback, FAT/SAT, handover and support boundaries.

How is PPC different from SCADA, RMS and EMS?

SCADA/RMS focuses on acquisition and operating visibility. PPC coordinates plant-level electrical control. EMS handles schedules and storage or hybrid dispatch. OEM protection retains local authority.

Can existing OEM equipment remain in scope?

Often it can, when the OEM interface, firmware, point list, network access and project responsibilities support the intended path. Compatibility is confirmed per model and project.

What information is needed before a technical workshop?

Bring the plant asset list, single-line diagram, signal list, controller and communications details, grid-interface requirements, applicable tender or utility documents and current acceptance records.

Are response time, compliance and compatibility guaranteed?

No universal guarantee should be inferred. These are project-defined and require a confirmed architecture, equipment scope, test method, applicable requirements and acceptance evidence.

What happens when communications or a command path fails?

The project should define the communications-loss state, command timeout, manual or local fallback, interlocks, alarm ownership and evidence required to demonstrate safe behaviour. The final rule belongs to the approved plant architecture.

Next step

Bring the plant boundary. We will make the control path reviewable.

Share the single-line diagram, plant stage, equipment and the decisions that need to be settled before commissioning or retrofit.