Monitoring and SCADA Specification for UK Utility-Scale Solar PV

Monitoring and SCADA Specification for UK Utility-Scale Solar PV: The Foundation EPC Contractors Cannot Afford to Overlook

According to data published by Solar Energy UK, the country now hosts over 15 gigawatts of large-scale ground-mounted solar capacity, with hundreds of new utility-scale projects progressing through planning and grid connection queues every year. Yet a disproportionate number of these projects encounter costly commissioning delays, lender reporting failures, and Distribution Network Operator (DNO) compliance issues that trace back to a single root cause: an inadequately specified Monitoring and SCADA Specification for UK Utility-Scale Solar PV. EPC contractors who treat SCADA as a procurement afterthought, rather than a contractually defined engineering deliverable, consistently create technical liabilities that surface only after the point of no return during grid connection testing, technical due diligence, or the first O&M performance review.

This article is written for EPC project managers, lead electrical engineers, and technical procurement leads who need to define their monitoring specification before submitting for grid connection approval. It covers every layer of the architecture from DNO telemetry obligations under G99 and G100, to IEC 61724-1 compliance, protocol selection, alarm hierarchy design, and what lenders genuinely expect in a bankable O&M monitoring package.

Why the SCADA Specification Must Be Written Before Grid Connection Approval

Most EPC contractors treat the monitoring and SCADA package as a late-stage procurement decision, often selected alongside inverters and string boxes during detailed design. This sequencing error is expensive. The DNO’s grid connection offer, issued under Engineering Recommendation G99 or G100 depending on connection voltage, contains specific technical requirements for telemetry, active power control, and reactive power management. These requirements must be architecturally incorporated into the SCADA system from day one not retrofitted after equipment is installed on site.

Consider what happened on a 49.9 MWp site in the East Midlands during commissioning. The EPC contractor had selected a market-leading inverter brand and a mid-tier monitoring platform. What they had not done was check whether the monitoring platform could receive and act on an active power reduction signal from the DNO in under ten seconds the threshold specified in the G99 connection agreement. The monitoring platform could log data. It could not execute control commands. A solar plant controller had to be procured, configured, and tested six weeks after energisation, delaying commercial operation by almost two months and triggering liquidated damages clauses. For the full pathway from design to grid connection approval, the SCADA specification must be locked before detailed design is complete.

G99 Monitoring Requirements and DNO Telemetry Under G99 and G100

G99 monitoring requirements are not optional compliance checkboxes. They are legally binding conditions attached to the grid connection agreement. For utility-scale solar PV connected at 11 kV and above, the connection agreement will typically mandate the following capabilities that the SCADA architecture must be able to deliver:

• Active power export limiting: The system must be capable of receiving a remote setpoint from the DNO or System Operator and reducing output to a defined MW or percentage figure within a specified response time, commonly between five and thirty seconds depending on the connection agreement.
• Reactive power control: The plant must be able to operate at a defined power factor range, typically between 0.95 leading and 0.95 lagging, with the plant controller able to dispatch reactive power setpoints to individual inverters or inverter groups.
• Frequency response: Under the grid code requirements applicable to larger installations, the SCADA and plant controller must be able to trigger curtailment responses when grid frequency exceeds defined thresholds, particularly the 50.5 Hz limit for low-frequency demand disconnection response.
• Telemetry data points to the DNO: Real-time transmission of active power, reactive power, voltage at the point of connection, and plant availability status. The communication channel, latency tolerance, and data format (typically IEC 60870-5-104 for DNO-facing interfaces) must be defined before grid connection testing can be scheduled.

DNO telemetry requirements often specify the exact communication protocol, the polling interval, the number of data points, and the alarm states that must be transmitted. A SCADA specification that does not explicitly address these requirements will fail the factory acceptance test (FAT) or the site acceptance test (SAT) at the point of commissioning. For EPC contractors who want to understand how these requirements fit into the broader design workflow, the PV solar system design process is an essential reference framework.

The Three Layers of Solar PV Data Acquisition: Why Conflating Them Costs You

One of the most persistent misunderstandings in EPC SCADA procurement is treating plant-level SCADA, inverter-level monitoring, and string-level data acquisition as interchangeable. They are not. Each layer serves a distinct technical and commercial function, and specifying only one or two of them creates gaps that surface in lender reporting reviews and O&M fault diagnosis typically at the worst possible moment.

Plant-Level SCADA

The plant-level SCADA system is the master control and data aggregation layer. It communicates with the solar plant controller, the grid protection relay, the on-site weather station, the revenue meter, and critically the DNO telemetry interface. It is the system that lenders and their technical due diligence advisors will interrogate when reviewing the project’s operational performance. A plant-level SCADA system must be able to produce timestamped performance reports aligned with IEC 61724-1 intervals, export data in a format acceptable to the lender’s independent engineer, and execute the control commands received from the DNO without human intervention.

Inverter-Level Monitoring

Inverter-level monitoring captures AC output data, internal fault codes, temperature readings, and DC input aggregates for each inverter or inverter cluster. This is the layer that enables O&M teams to diagnose whether a performance shortfall is caused by a clipping event, an MPPT fault, a thermal derating condition, or a DC input imbalance. Most inverter manufacturers supply proprietary monitoring portals that capture this data. The problem is that these portals are manufacturer-specific, do not aggregate with the plant-level SCADA, and are often inaccessible to the asset owner or the O&M contractor without vendor involvement. The EPC specification must require a standardised communication interface typically Modbus TCP or IEC 60870-5-104 that allows the plant-level SCADA to ingest inverter data directly.

String-Level Data Acquisition

String-level monitoring, delivered through smart combiner boxes or string monitoring units, is the most granular layer. It captures DC current per string, enabling fault detection at the level of individual string circuits. On a 20 MWp site with 1,500 strings, this is not a luxury feature it is the only practical way for an O&M team to identify a single open-circuited string, a partial shading anomaly, or a bypass diode failure without commissioning a full thermal imaging survey. The specification must define the polling interval (typically one minute or less for effective fault response), the data retention period, and how string data is surfaced within the plant-level SCADA alarm hierarchy.

IEC 61724-1 Compliance: What Most Contractor-Grade Monitoring Packages Miss

IEC 61724-1 is the international standard for photovoltaic system performance monitoring. Its requirements govern irradiance measurement, data logging resolution, sensor calibration, and the calculation methodology for key performance indicators including Performance Ratio (PR) and System Availability. Technical due diligence advisors working for project finance lenders will check whether the monitoring system is IEC 61724-1 compliant. Many contractor-grade monitoring packages that are marketed as “IEC 61724 compliant” satisfy only the minimum interpretation of the standard and fall short on three specific requirements that are consistently identified in TDD reports.

Irradiance Sensor Placement and Calibration

IEC 61724-1 requires that the irradiance sensor be mounted in the plane of the array (POA), at a tilt and azimuth matching the modules, within a defined proximity to a representative section of the array. The standard also specifies that a secondary reference cell or pyranometer be used to enable cross-validation. Where a site uses single-axis tracking, the sensor must track with the array. The calibration interval for reference cells under IEC 61724-1 is annually for Class A systems the class required for utility-scale reporting with calibration traceable to a UKAS-accredited laboratory. Projects that install a fixed irradiance sensor on a tracker site, or that operate with a calibration certificate that is more than twelve months old, will produce PR calculations that are neither technically valid nor lender-acceptable.

Data Logger Resolution and Timestamp Integrity

The standard requires a minimum data logging resolution of one minute for Class A systems and defines strict requirements for timestamp synchronisation, typically GPS or NTP-referenced time. Logger drift of even a few seconds per day can introduce systematic errors into PR calculations over a full year of operation. Many lower-cost data loggers do not use NTP synchronisation and accumulate drift that is invisible in daily reports but becomes statistically significant in annual lender reporting periods. The PVSyst simulation framework used during energy yield assessment assumes measurement quality consistent with IEC 61724-1, so if the as-built monitoring system uses lower-resolution logging, the performance comparison against the P50 prediction is fundamentally compromised.

Communication Protocol Selection: The Most Common SCADA Commissioning Failure

Protocol mismatch between inverters, combiner boxes, and the plant controller is without qualification the most frequent cause of SCADA commissioning delays on UK utility-scale solar sites. The reason is that EPC contractors often specify the monitoring platform and the inverters separately, without verifying whether the communication interfaces are natively compatible or require gateway devices, custom drivers, or vendor-supplied middleware that is not included in either equipment supply contract.

The Core Protocol Landscape for Solar PV Data Acquisition

• Modbus RTU: A serial protocol widely supported by inverters, smart meters, and weather stations. Effective for short cable runs within a single inverter station but inherently limited in terms of network scalability and error detection. Not suitable as the primary protocol for plant-level SCADA on sites larger than approximately 5 MW without significant gateway infrastructure.
• Modbus TCP: The Ethernet-based version of Modbus, substantially more scalable and appropriate for inverter-to-SCADA communication on medium and large utility-scale sites. However, it is still a polling-based protocol, meaning the SCADA system must actively request data from each device. On a site with 40 or more inverters, polling cycle time must be carefully engineered to ensure all data is refreshed within the required one-minute window.
• IEC 60870-5-104: The protocol most commonly mandated by DNOs for telemetry interfaces and increasingly adopted by plant controllers and SCADA platforms for their upstream reporting functionality. It is a report-by-exception protocol, meaning devices transmit data when values change rather than only in response to polling, which significantly reduces latency for control command delivery. This is the protocol most EPC contractors need to specify for the DNO-facing interface.
• DNP3: Common on sites with Transmission System Operator interfaces or where the project has National Grid ESO obligations. Less frequently mandated by distribution-connected solar PV but increasingly relevant as projects connect at higher voltages or participate in balancing mechanism services.

The specification document must define which protocol is used at each interface layer: inverter to local data concentrator, data concentrator to plant controller, plant controller to plant-level SCADA, and SCADA to DNO telemetry. A site that uses Modbus TCP from inverters to SCADA but receives a G99 connection agreement mandating IEC 60870-5-104 for the DNO interface must include a protocol conversion gateway and that gateway must be specified, procured, tested, and included in the commissioning scope before grid connection testing begins. For EPC contractors developing site layouts where communication cable routing is part of the design, the AutoCAD solar planning process is the appropriate stage to define communication infrastructure routing.

Solar Plant Controller: The Critical Interface Between SCADA and the Grid

The solar plant controller is the functional component that receives setpoints from the DNO or System Operator and dispatches corresponding commands to individual inverters or inverter groups. It is distinct from the SCADA monitoring platform, which primarily aggregates and visualises data. Many EPC contracts either omit the plant controller from the scope entirely assuming the SCADA platform can perform this function or procure it as a standalone device without defining its integration requirements with either the inverters or the SCADA system.

The plant controller specification must define response time from setpoint receipt to full inverter adjustment, accuracy tolerance for power delivery against the setpoint, behaviour during communication loss (fail-safe modes), and integration with the protection relay system. For projects in the UK participating in the Smart Export Guarantee or grid services contracts, the plant controller’s response characteristics directly affect revenue performance and must be validated during commissioning against the performance thresholds in the connection agreement.

Alarm Hierarchy, Availability Calculation and Data Export: What Lenders Actually Require

A monitoring specification that defines sensors and protocols but does not address alarm hierarchy design, availability methodology, and data export format is incomplete for lender and O&M purposes. These three elements are what the asset owner’s O&M contractor and the lender’s independent engineer will interact with on a daily and quarterly basis throughout the asset’s operational life.

Alarm Hierarchy Design

A utility-scale solar PV site can generate thousands of alarm events per day if the alarm system is not properly configured. The specification must define alarm priority levels typically Critical, Major, Minor, and Informational and assign each alarm type from each device class to the appropriate level. A grid protection relay trip is a Critical alarm requiring immediate response. An inverter fan fault is a Major alarm requiring next-day attention. A communication timeout on a single string monitoring unit is a Minor alarm. Without this hierarchy defined in the specification, O&M teams face alarm flooding, miss genuine critical events, and are unable to demonstrate that the monitoring system meets the site availability requirements in the O&M contract.

Availability Calculation Methodology

Availability is a commercial metric with financial consequences: O&M contracts include availability guarantees, and the definition of availability must be mathematically unambiguous. The specification must define whether availability is calculated on an energy basis (comparing actual generation to the generation that would have occurred under the same irradiance conditions without any downtime) or on a time basis (percentage of operational minutes in the measurement period). It must also define which loss categories count against availability inverter downtime, planned maintenance windows, grid curtailment events and how these are classified and logged within the SCADA system. Lenders’ independent engineers will reject availability reports where the calculation methodology is undefined or inconsistently applied.

Data Export Format Requirements

The SCADA system must be capable of exporting performance data in formats acceptable to the lender’s independent engineer and the O&M contractor. Commonly required formats include timestamped CSV exports at one-minute and fifteen-minute intervals, PDF summary reports aligned with lender reporting periods, and API-accessible data feeds for integration with the asset manager’s portfolio monitoring platform. The specification must define data retention periods typically a minimum of ten years for utility-scale assets and whether data is stored on-site, in a cloud-based platform, or both, with defined backup and recovery procedures.

Writing the SCADA Specification Document: A Structural Framework for EPC Contractors

A bankable SCADA specification is a standalone engineering document not a section within the electrical design package. It should be structured around the following content areas, each of which must be addressed with sufficient technical specificity to be tested during factory acceptance and site acceptance testing:

1. System architecture overview: Defining all monitoring layers, device types, communication paths, and the DNO telemetry interface in a single architecture diagram with a supporting narrative.
2. DNO interface specification: Extracted directly from the G99 connection agreement, listing each required control function, data point, protocol, polling interval, and response time requirement.
3. Sensor specification: Defining irradiance sensor type (reference cell or thermopile pyranometer), placement coordinates relative to the array, calibration standard, and calibration interval consistent with IEC 61724-1 Class A requirements.
4. Communication protocol matrix: A table listing each interface between device pairs (inverter to data concentrator, data concentrator to plant controller, plant controller to SCADA, SCADA to DNO) with the specified protocol, physical medium, baud rate or IP addressing scheme, and data point list.
5. Alarm hierarchy register: A complete list of alarm types by device class, assigned priority level, required notification method, and maximum response time.
6. Performance calculation methodology: Defining the KPIs to be calculated (PR, Availability, Specific Yield), the data inputs for each, the calculation formula, the measurement interval, and the loss category classification scheme.
7. Data export and reporting requirements: Defining export formats, reporting periods, data retention duration, and the API or data feed specifications required by the asset manager.
8. Acceptance testing criteria: Listing the specific tests to be performed at FAT and SAT to verify that each specification requirement has been met, including protocol interoperability tests, control command response time tests, and alarm simulation tests.

This document should be issued to all potential SCADA suppliers as part of the tender package and used as the basis for technical evaluation. Suppliers who cannot demonstrate compliance with each section should not be shortlisted regardless of commercial considerations.

Conclusion: SCADA Specification Is a Pre-Construction Engineering Deliverable

The central message of this article is straightforward: the monitoring and SCADA specification for a UK utility-scale solar PV project is not a commissioning-phase document. It is a pre-construction engineering deliverable that must be completed before detailed design is finalised, before equipment is procured, and before the grid connection testing programme is agreed with the DNO. Every delay, every lender reporting failure, and every G99 compliance issue that stems from an inadequate monitoring architecture was preventable and was preventable at the specification stage.

EPC contractors who define the three-layer architecture, lock the protocol matrix, embed the G99 and G100 telemetry requirements, specify IEC 61724-1 Class A sensor standards, design a structured alarm hierarchy, and define the availability calculation methodology before procurement have a fundamentally different commissioning experience from those who do not. The monitoring system becomes a bankable asset rather than a liability. Lenders’ independent engineers find what they need in the format they require. O&M teams can diagnose and resolve faults without delay. And the DNO grants grid connection approval on schedule.

For EPC contractors and project developers looking to build this level of technical rigour into their solar development process, the engineering disciplines covered in this article connect directly to the upstream design and planning work required at every project stage. A well-executed monitoring specification begins with a well-executed design process and that process starts long before the first panel is installed on site.