Solar Data Acquisition System (DAS) Tagging: Units, Scaling, and QC for Utility-Scale PV

In a utility-scale solar plant, your solar data acquisition system (DAS) is only as trustworthy as the “last mile” details: point naming, units, scaling, and quality control (QC). When those basics are wrong (or inconsistent), the symptoms show up everywhere—incorrect KPIs, failed performance reports, confusing alarms, and long troubleshooting loops that feel like “mystery data gaps.”

This article is for solar owners/operators, developers, EPCs, and O&M teams who want a grounded, commissioning-ready approach to solar data acquisition system (DAS) tagging. Specifically, you’ll learn how to define units, apply scaling without surprises, and validate signals end-to-end so your SCADA screens, historian data, and reports agree.

Solar data acquisition system (DAS) tagging: quick definitions (units, scaling, QC)

Before we get tactical, here’s what these terms mean in day-to-day project work.

• DAS tagging: the convention for identifying each data point (tag name), describing it (metadata), and ensuring downstream systems (SCADA/HMI, historian, reports) interpret it correctly.
• Units: engineering units that describe the quantity (kW, kWh, V, A, Hz, W/m², °C, m/s, %, etc.).
• Scaling: the math that converts a raw value (counts, register value, mA signal, vendor-specific encoding) into engineering units.
• QC (quality control): the test process and acceptance criteria that prove the tag is correct at every layer (device → network → SCADA/DAS server → historian → report).

At a systems level, a solar data acquisition system (DAS) includes sensors/instruments, signal conditioning, data logging/measurement, and communications—so each layer can introduce unit/scaling errors if it’s not documented and tested. Renesas’ DAS design note is a useful general reference for how conditioning, conversion, and throughput constraints shape reliable acquisition. Meanwhile, HeatSpring’s utility-scale PV DAS overview is a practical PV-oriented reference for typical equipment and why weather and metering signals matter during testing and operations.

Why solar DAS tagging mistakes are so expensive after COD

Tagging errors rarely look like “the DAS is down.” Instead, they look like:

• power or energy values that are consistently off by 10x or 1000x,
• irradiance values that are plausible but wrong (bad scaling, wrong sensor constant),
• meter values that don’t match revenue-grade expectations (CT/PT ratios or register interpretation issues),
• temperature or wind values that drift or flatline without obvious alarms,
• reports that disagree with SCADA screens (different scaling in different layers).

Fixing this after COD is costly because changes ripple through historian mappings, dashboards, performance models, alarm thresholds, and sometimes contractual reporting. For that reason, the most practical strategy is to treat unit/scaling and QC as commissioning deliverables—not “cleanup later.”

A solar data acquisition system (DAS) tagging deliverable: what your point list should contain

The point list (sometimes called a tag list or I/O list) should be more than tag names. In practice, it becomes the single source of truth that engineering, commissioning, and O&M can rely on.

Minimum fields for a solar DAS point list (recommended)

• Tag name (unique and stable)
• Description (plain language)
• Asset hierarchy (plant/subsystem/device, e.g., Inverter 12, Meter Main, MET)
• Signal type (analog, digital, counter, string, quality)
• Engineering units
• Raw source (protocol + register/point ID + data type)
• Scaling definition (formula, multiplier/divider, offset, and any vendor-specific encoding notes)
• Expected range (normal operating band + “sanity limits”)
• Update rate (poll interval or event-driven)
• QC test method (how you will prove it’s correct)
• Historian requirements (archive yes/no, sample/avg, compression/deadband)

In addition, it helps to tie points to your hardware bill of materials (BOM) so field teams can verify sensors, transducers, and wiring match the design intent. For a practical example of how solar DAS scope is often framed around loggers, sensors, meters, and integration components, see this overview of DAS BOM elements from Nor-Cal Controls. (DAS BOM overview)

Solar DAS units: choose one “truth” and stick to it

Unit inconsistency is one of the fastest ways to break data trust. The fix is simple: define a plant-wide unit standard and apply it in every layer (device config, SCADA/DAS mapping, historian, reporting).

Common unit decisions that should be explicit in a solar data acquisition system (DAS)

• Power: kW vs W vs MW
• Energy: kWh vs Wh vs MWh (and whether the signal is an accumulating total or interval energy)
• Voltage/current: V, A (including whether values are line-to-line, line-to-neutral, phase, or average)
• Frequency: Hz
• Irradiance: W/m² (confirm sensor output and calibration factor)
• Temperature: °C vs °F (most utility-scale analytics assume °C)
• Wind speed: m/s vs mph
• Angles: degrees (tracker/mount positions)
• Power factor: unitless (often shown as PF, sometimes signed)

Practical rule

If an operator or analyst has to ask “is this kW or W?” more than once, the system is already costing time. Therefore, units should be visible in SCADA and encoded in your point list metadata so reports can’t “guess.”

Solar DAS scaling: where most “looks fine” signals go wrong

Scaling converts raw numbers into engineering units. In solar plants, scaling errors typically come from one of four places:

• Sensor/transducer math: for example, 4–20 mA mapping, sensor sensitivity, shunt/CT conversions.
• Protocol/register interpretation: signed vs unsigned integers, floating point formats, endianness, word order, or vendor-defined scaling registers.
• Multi-layer scaling: scaling applied in the device and again in the SCADA/DAS mapping (double-scaling), or applied nowhere.
• Ratio configuration: meter CT/PT ratios and scaling for engineering outputs.

Design guidance for acquisition systems emphasizes that analog front-end choices (amplification, filtering) and conversion resolution affect accuracy and reliability. Similarly, at the tag layer: if you don’t define scaling clearly, you can’t claim accuracy. (DAS design considerations)

Scaling pattern #1: linear scaling (multiplier + offset)

This is the most common case for sensors and some device registers.

EngineeringValue = (RawValue × Multiplier) + Offset

Examples:

• 0–10 V input representing 0–1000 W/m² (Multiplier 100, Offset 0)
• 4–20 mA representing -40 to 60 °C (Multiplier 6.25, Offset -65) depending on input card mapping

Scaling pattern #2: ratio scaling (CT/PT and similar)

For meters and some current/voltage measurements, the raw value may be “secondary” and needs conversion to primary using ratios. However, if these ratios are wrong, the data can be consistently wrong while still looking stable.

PrimaryValue = SecondaryValue × Ratio

Where the ratio may be CT ratio, PT ratio, or combined.

Scaling pattern #3: vendor-defined scaling registers or enumerations

Some devices provide:

• a value register and a separate scale register (e.g., exponent), or
• a raw value that must be interpreted based on a documented format.

In that case, scaling belongs in one layer (preferably where it’s easiest to audit and version-control). Also, document it in your point list as “source-of-truth scaling.”

A simple table to prevent the most common scaling failures

Solar data acquisition system (DAS) QC: prove the signal end-to-end

QC should verify three things for each critical point: (1) the value is right, (2) the unit is right, and (3) the timestamp and quality are right.

In practice, a solar DAS exists to provide comprehensive visibility and alerting across plant equipment and sensors, including MET instrumentation that supports acceptance testing and performance evaluation. As a result, QC is especially important for weather and metering points. (Utility-scale PV DAS context)

QC tiering: test depth based on risk

Not every tag deserves the same test effort. A practical approach is to define tiers:

• Tier 1 (must be perfect): revenue-grade meter points, POI/substation measurements, plant power, curtailment setpoints/limits, key inverter power and status, key MET points used in performance tests (GHI/POA, module temp, ambient).
• Tier 2 (important for availability): inverter fault detail, tracker stow/fault states, comms health, switch/UPS statuses, derived KPIs used in dispatching.
• Tier 3 (nice to have / informational): secondary diagnostics that do not drive contractual reporting or operations decisions.

End-to-end QC methods (choose what fits the point)

• Reference comparison: compare DAS reading to a trusted reference (handheld meter, device local display, calibrated instrument).
• Stimulus test: inject a known signal (where safe and permitted) and confirm the value arrives correctly.
• Cross-system comparison: compare inverter-reported power to plant meter totals (with expected losses/tolerances).
• Range/sanity checks: enforce physics-based bounds (e.g., irradiance at night should be near zero; wind speed shouldn’t be negative).
• Data completeness checks: confirm points are continuously recorded at expected intervals, with quality flags.

A practical QC checklist for a solar data acquisition system (DAS)

1. Confirm the tag exists in SCADA/HMI and in the historian (if required).
2. Verify engineering units match the point list.
3. Check scaling by comparing against a trusted reference at two operating points (low and high, if possible).
4. Make sure timestamps align (time sync) and quality flags behave during comms interruptions.
5. Ensure alarm thresholds (if any) are in the same units as the displayed value.
6. Record the test result, reference used, and pass/fail with date and tester initials.

Solar DAS tagging examples (units + scaling + QC) for common PV subsystems

Below are examples of how to document a tag so it’s auditable.

Example 1: POA irradiance (MET station)

• Tag: MET01_POA_Irradiance
• Units: W/m²
• Scaling: based on sensor output + input module scaling (document sensor sensitivity or transmitter mapping)
• Expected range: 0–1300 W/m² (site-dependent)
• QC: compare against MET station display or logger raw channel; validate night-time baseline near zero; validate midday reasonableness relative to clear-sky expectations

Example 2: revenue meter real power

• Tag: MTR01_kW
• Units: kW
• Scaling: confirm register type and that CT/PT ratios are correctly configured (or applied in mapping if not configured in device)
• Expected range: -Pmax to +Pmax depending on import/export rules (site-specific)
• QC: compare against meter front panel or utility test set data (as applicable); verify sign convention during known export/import conditions

Example 3: inverter AC power

• Tag: INV12_AC_kW
• Units: kW
• Scaling: confirm whether inverter provides kW directly or W, and whether register already includes scaling
• QC: compare to inverter local HMI; verify aggregation logic (sum of inverters vs plant meter) within expected tolerance

Historian and reporting: keep one source of truth for solar DAS tags

Many teams unintentionally create two sources of truth:

• SCADA shows engineering units with one scaling approach,
• historian stores raw values (or differently scaled values),
• reports apply additional transformations.

That’s a recipe for disputes and wasted time. Instead, use this practical standard:

• Historian stores engineering units (already scaled) whenever possible.
• Reports do not rescale—they calculate KPIs from consistent engineering-unit tags.
• All transforms are documented (e.g., any derived calculations) and version-controlled.

Documentation that prevents “tribal knowledge” operations

At handoff, a plant should not require “the one person who knows the tags.” The minimum documentation package that supports long-term ops includes:

• as-built point list (including units, scaling, ranges, and QC methods),
• QC test records (what was tested, how, and results),
• network and communications drawings (including key comms paths),
• alarm list with priorities and thresholds tied to units,
• a change log for tag modifications post-commissioning.

Where REIG fits: commissioning-ready solar data acquisition system (DAS) tagging

REIG’s integration approach is built around making plant data dependable from day one: a commissioning-ready SCADA + DAS stack, standardized deployments (including rugged RenergyWare enclosures/hardware configurations), and end-to-end verification that reduces rework and shortens the path to COD. Ultimately, the goal is fewer surprises during commissioning, and fewer “is it comms or is it equipment?” troubleshooting loops after handoff.

Action plan: implement a solar DAS tagging standard in the next 2–4 weeks

1. Pick Tier 1 points (meters, POI, plant totals, key MET, key inverter power/status) and lock unit standards.
2. Define where scaling lives (device vs SCADA mapping) and remove any double-scaling paths.
3. Add expected ranges to the point list for fast sanity checks.
4. Run end-to-end QC on Tier 1 points and document results.
5. Confirm historian alignment (engineering units stored, sample intervals, and quality flags).

Conclusion: clean solar DAS tags are a reliability feature

A solar data acquisition system (DAS) is not “just data.” It’s the evidence you use to commission the plant, prove performance, and troubleshoot quickly for years. When units, scaling, and QC are done in a commissioning-ready way, your SCADA screens, historian, and reports match—and teams stop wasting time arguing with the data.

If you’re building a new plant or cleaning up recurring data quality issues, REIG can help you standardize a commissioning-ready tagging and validation approach across your SCADA + DAS stack—so your team can trust the data and move faster.