Quality of data in renewable assets: what QA and QC mean in practice

Renewable resource engineers use "QA/QC" as a compound acronym — almost a single noun. It's part of the vocabulary of the sector forever. The problem is that QA and QC are different things, they happen at different times of the project, and confusing them has a concrete operational cost: projects that invest in QC and neglect QA spend ten times more to achieve the same result — when they arrive.

This note is not an introduction to ISO 9000. It is about what the distinction changes on the working day of an engineer who deals with daily solar or wind campaign data.

Where the distinction comes from

The formal definition comes from the ISO 9000 family of standards, which precisely separates the two functions:

Quality Assurance (QA) • quality assurance is the set of planned and systematic activities that it establishes confidence that a product or service will meet quality requirements. QA acts in the process. Its goal is to prevent defects from happening.

Quality Control (QC) — quality control — is the set of techniques and activities used to verify whether the quality requirements have been attended. QC acts on the product. Its goal is to detect defects that have already happened.

The difference is not of intensity, but of temporality and object: QA looks to the future (how will we ensure that the given will be good?), QC looks to the past (the given that arrived is good?).

What the engineer does at 8:00 a.m.

In an active campaign — solar or wind — the first task of the morning is usually the same: open the data panel, see what came from the logger during the night, and identify if there is any problem. That is pure QC.

The actions are verification and inspection:

• Download the data for the period and check the transmission integrity
• Check if the registry count is correct (expected: 144 records of 10 min per day)
• Roll physical range checks (GHI < 0, speed < 0, temperature off track)
• Check persistence: some value repeated by more than N consecutive records? (see NT.12)
• Compare to the redundant sensor: any divergences out of the way?
• Calculate the κ_cs of the previous day: is the trend of falling dirt?
• Document any new flag in the incident log

All this is product verification (the fact that it has arrived). The engineer is not changing the measurement process — he is inspecting its result.

The time that this process takes is directly proportional to the quality of the QA that was made before the campaign. With good QA, the daily review is quick: automatic checks run without intervention, the flags are rare and well categorized, and the engineer ends in 30 minutes. With bad QA — poorly calibrated sensors, absent redundancy, inconsistent naming protocol — each data day requires manual research that can consume hours.

What defines before the first measurement

QA, in renewable resource campaigns, occurs mainly in two moments: during the planning of the campaign and during the installation of the instruments. These decisions determine the quality structure that the QC will have to inspect in the following months.

During the planning:

• Specification of the instrument according to the reference standard (ISO 9060 Class A pyranometer for IEC 61724-1, MEASNET certified anemometer for IEC 61400-12-1)
• Definition of redundancy: how many sensors per variable, backup configuration
• The nameing protocol of variables (consistency between portfolio projects)
• – Calibration and maintenance schedule (maximum interval between cleanings for semi-arid-climate pyranometers)
• Definition of the validity criteria of the data: which automatic checks will run, in which sequence, with which threeholds
• The gap-filling protocol: when to interpolate, when to use reanalysis, when to invalidate the period

During installation:

• Alignment of the piranometer (horizontality, orientation, free shading for zenith angle < 85°)
• Anemometer positioning (obstacle distance, free angle of the tower belt, orientation boom according to MEASNET)
• Data logger configuration (sampling rate, timestamp format, decimal resolution)
• Communication verification and first set of commissioning data

None of these activities is "data inspection" — they are process decisions that determine whether the data will exist and with what reliability. They are QA.

Why the report requires both

When a lender orders an independent review (due diligence technique), the reviewer asks two sets of different questions:

Questions from QA (Procedure):

• Was the instrument suitable for the applicable standard? (ISO 9060 Class A for IEC 61724-1?)
• Did the installation follow the reference protocol? (good documented orientation?)
• Was the calibration interval respected? (Certificate of calibration within the time frame?)
• Was there a redundant sensor for the primary variable?
• Was the gap-filling protocol defined before the start of the campaign or ad hoc during the analysis?

QC Questions (product):

• What flags have been generated and how have they been solved?
• What is the final availability by variable and period?
• What gaps have been filled out, with what method and with what uncertainty added?
• Is there any evidence of calibration drift or dirt in the data?
• Has the cross-consistency between sensors been verified?

A report that responds well to QC questions but not to QA questions raises systemic doubt: the data may be well treated, but what about the process that generated it? A report that responds well to QA questions but not to QC questions punctually: the process was good, but the data was careful? Both dimensions are necessary.

The feedback that closes the cycle

The distinction between QA and QC only generates operational value when there is a functioning feedback mechanism: what the QC finds should update the QA.

Specific examples:

• QC detects dirt progressing faster than expected in summer → QA updates the cleaning protocol for monthly interval instead of bimonthly for campaigns in the region
• QC identifies recurring stuck value in the same sensor at 14h → QA investigates watchdog configuration of the data logger and fixes firmware before next project
• QC finds systematic gap in 72 hours of data every time there is rain → QA reviews the IP protection specification of the data logger for the next tropical climate project

Without this mechanism, the organization executes each zero project from the point of view of QA — and the QC continues to find the same flaws repeatedly, in each different campaign. The accumulated cost is invisible because it appears distributed among projects, but it is real.

The cost of finding the fault late

The cost curve grows nonlinearly because what is being corrected changes as the phase progresses. In planning, correcting an inappropriate protocol costs a meeting and a document update. In installation, correcting an improperly specified sensor costs field rework. During data operation, correcting a problem identified by the daily QC costs hours or days of data (as discussed in NT.12In the analysis, correcting a problem that should have been solved before may require reworking months. After the report, what was wrong in the measurement process requires a new campaign — and a new report, a new deadline, a new round of due diligence.

The confusion that costs a lot

The most common mistake in projects that arrive for review is not to make bad quality QC. It is to invest a lot in QC and little in QA — and then be surprised that the QC encounters problems that cannot be solved.

An engineer who reviews daily data with rigor (good QC) but who operated with a single unredundant (insufficient AQ) pyranometer will identify the sensor failure on the right day — and will not be able to reconstruct the data from that period. The QC detected; had not been able to recover. Good AQ would have guaranteed a backup sensor: when the primary failed, the secondary would have continued to record.

Inversely, a project with good QA — calibrated sensor, installation according to standard, configured redundancy — produces data that require very little of the daily QC. Flags are rare because the process was correct from the start. The engineer reviews in minutes and follows for analysis. The QC load is proportional to the quality of the previous QA.

In the practice of renewable assets, the availability discussed in NT.01 and the QA/QC checks of piranometers of NT.03 They are QC tools — product inspection. The measurement protocol that defines which of these checks will be executed, with which thresholds, in which software, with which audit trail — this protocol is QA. There is no effective QC without QA that defines what the QC should verify.