Solar DAS Commissioning Targets: Completeness, Accuracy, Latency

On a utility-scale PV project, “DAS is online” is not the same thing as “DAS is commissioned.” A screen full of tags only proves the plant can talk. Commissioning proves something harder: the right signals exist, the values mean what you think they mean, and they arrive fast enough to support operations, KPIs, and (when applicable) utility-facing testing.

This guide is for owners/operators, developers, EPCs, commissioning leads, SCADA/DAS engineers, and O&M teams who need to define acceptance targets for solar DAS commissioning. We’ll use three field-practical lenses—completeness, accuracy, and latency—so you can prevent late-stage rework and avoid handing O&M “mystery” data gaps after COD.

Quick definitions (so you can scope and accept cleanly)

DAS vs SCADA (why it affects commissioning targets)

DAS (Data Acquisition System) is the monitoring and data pipeline: sensors, meters, device data, storage/historian, dashboards and reports. SCADA includes data acquisition plus supervisory control (setpoints, curtailment modes, utility/ISO command paths). On many plants, the same infrastructure supports both, so weak DAS commissioning often turns into SCADA delays later.

What “commissioning targets” mean

Commissioning targets are measurable acceptance criteria that tie directly to outcomes: COD readiness, stable KPIs, fast troubleshooting, and defensible reporting. In this article, targets fall into three buckets:

• Completeness: all required signals exist, map correctly, and have usable documentation and evidence.
• Accuracy: values are correct end-to-end (device to historian), including units, scaling, signs, timestamps, and quality behavior.
• Latency: data arrives quickly and consistently enough for your operational and contractual use cases.

The commissioning lens that prevents rework: Measurement, Meaning, Timing

Most late-stage DAS pain comes from unowned boundaries. Use this lens to force end-to-end proof instead of “it shows up on the dashboard.”

1. Measurement: Is the underlying device reading correct (wiring, CT/PT ratios, sensor alignment, calibration, device configuration)?
2. Meaning: Do units, scaling, sign conventions, timestamps, and quality flags stay consistent through every boundary (RTU/datalogger, gateways, SCADA/DAS platform, historian, dashboards)?
3. Timing: Does the data arrive with the latency and update behavior you actually need (poll rate, buffering, network performance, historian write timing)?

Target #1: Completeness (the plant has the whole dataset you intended)

Completeness is not “all possible points.” It is “the points required to operate, report, and troubleshoot are present, defined, and proven.” If your team doesn’t define completeness, commissioning turns into a tag-by-tag argument under schedule pressure.

Completeness acceptance criteria (practical)

• Point list is testable: source device, protocol, address/register, data type, byte/word order, scaling math, units, expected ranges, scan rate, historian logging, and quality rules.
• Critical signals exist at every layer: device → gateway/RTU/datalogger → DAS ingestion → historian → reports/dashboards.
• Required KPIs can be computed without “special handling”: PR/availability/curtailment inputs (as defined by the owner/O&M) are present and consistent.
• Documentation is complete enough to troubleshoot: as-builts, network/IP plan, device inventory, configuration backups, and evidence package are delivered and organized.

What to include in a “minimum operational dataset” (utility-scale PV)

Every plant differs, but most utility-scale sites should treat the following as completeness-critical:

• For example, POI / plant metering: MW, MVAR (if tracked), energy counters, voltage, frequency, breaker/status points as applicable.
• Additionally, inverters: power, energy, operating state, key faults/alarms, comms health (selectively—avoid “trend everything”).
• Likewise, trackers (if used): position, stow states, key alarms, comms health.
• Meanwhile, MET / irradiance: POA/GHI as required, module/ambient temps; include calibration metadata and scaling location.
• In addition, network health indicators: managed switch status/ports (where available), gateway status, key link health alarms.
• Finally, data quality states: stale/bad/substituted rules implemented so missing comms does not silently masquerade as “good data.”

Completeness test plan (fast to execute, hard to argue with)

1. Freeze a revision-controlled point list and align it to owner, EPC, and O&M expectations.
2. Next, run an ingestion audit: confirm every point exists in DAS and maps to the expected device/register.
3. Then, perform a historian audit: confirm key points are stored (not only displayed) and can be retrieved with correct units and timestamps.
4. Finally, run a report audit: run a “day-in-the-life” interval and confirm dashboards/reports can compute without manual patching.

Target #2: Accuracy (values are correct and defensible end-to-end)

Accuracy is where “online but wrong” shows up: wrong registers, swapped word order, incorrect signed/unsigned interpretation, CT/PT ratio issues, double scaling, or time drift that breaks KPI math. Good accuracy commissioning starts at the device and ends in the historian.

Accuracy acceptance criteria (what to require)

• First, device truth verified: compare SCADA/DAS values to known-good references (meter front panel, handheld measurement, device local UI, calibrated instruments).
• Next, scaling applied once: document where scaling happens (sensor/datalogger vs RTU vs DAS platform) and prove there is one and only one conversion.
• Additionally, sign conventions are aligned: especially at POI for import/export and MVAR sign behavior.
• Moreover, units are consistent across layers: for example, W/m² vs kW/m², kW vs MW, and temperature units.
• Finally, time sync validated: NTP (or GPS time) configured and verified so timestamps align across devices and the historian.

Accuracy test methods by signal type

Accuracy “red flags” that should stop acceptance

• For example, HMI looks right but historian export is wrong (two truths).
• Additionally, irradiance or temperature units vary between dashboards and historian tags.
• Meanwhile, POI MW sign convention is “still being debated.”
• As a result, quality flags are always “good,” even during comms dropouts.
• Finally, time sync is not verified, only “assumed.”

Target #3: Latency (data arrives fast enough to be operationally useful)

Latency is often treated as an IT detail, but in commissioning it becomes a visibility and troubleshooting problem. High or inconsistent latency can cause operators to chase phantom issues, make control and curtailment attribution harder, and complicate witness testing where response timing matters.

What latency means in a solar DAS context

Latency is the delay between a value changing at the source and that change being usable at the destination (HMI/historian/report). It includes device update behavior, protocol polling intervals, network transport, buffering, server processing, and historian write strategy.

Latency targets to define (before field testing)

Instead of one blanket requirement, define latency targets by use case:

• For example, operational monitoring: enough to diagnose outages/derates quickly (often driven by scan rate and historian write interval).
• Meanwhile, KPIs and reporting: stable time alignment and consistent averaging windows (more important than “fast”).
• Additionally, alarm response: critical alarms should appear quickly and reliably, not minutes later.
• Finally, utility/SCADA boundary (if applicable): any controls/telemetry timing requirements should be mapped to a test method and measured at the defined boundary.

How to test latency without overcomplicating it

1. Pick a small set of representative points: POI MW, one inverter MW, irradiance, one status bit/alarm.
2. Create a timestamped stimulus: a controlled change (safe setpoint step where applicable, or a known state change).
3. Measure arrival times at each boundary: device/local UI → gateway/RTU → DAS UI → historian record → dashboard/report.
4. Document the scan rates and confirm they match the point list, not “whatever the server ended up doing.”

Common latency causes (and how to fix them)

• For example, overloaded polling: too many points at aggressive scan rates. Fix by prioritizing critical points and staging non-critical expansion.
• Additionally, network instability: intermittent packet loss can look like high latency. Fix with managed switch discipline, topology clarity, and baseline fiber verification where fiber is used.
• Moreover, historian/write settings: misconfigured compression/deadbands can create the illusion of “slow data.” Fix by aligning historian strategy to operations needs.
• Finally, time sync issues: sometimes perceived latency is actually timestamp drift. Fix by verifying NTP everywhere early.

The commissioning deliverables package (tie targets to evidence)

If you want to hit COD without a post-turnover cleanup project, contract for deliverables and acceptance evidence. The deliverables below map directly to completeness, accuracy, and latency targets.

A simple scoring rubric you can use in the field

If you need to decide “are we done?” during a busy commissioning window, use a short rubric. Score each category 0–2 and require a minimum score for acceptance.

• First, completeness (0–2): 0 = partial/informal tags; 1 = mostly present but gaps; 2 = all required points + docs + evidence.
• Next, accuracy (0–2): 0 = unverified; 1 = spot-checked only; 2 = verified against references + historian truth + time sync proven.
• Finally, latency (0–2): 0 = unknown/unreliable; 1 = acceptable sometimes; 2 = measured, consistent, and aligned to scan/historian strategy.

When any category is below target, the fix should be a written punch item tied to evidence, not an open-ended “we’ll tune it later.”

Where REIG fits: commissioning-ready SCADA + DAS integration

Renewable Energy Integration Group (REIG) is a solar SCADA and DAS integration contractor delivering end-to-end design, installation, commissioning, and ongoing support for utility-scale PV. REIG’s commissioning-ready approach focuses on owning the boundaries that cause schedule pain: point discipline, network and communications integration (including fiber verification), historian integrity, and clean turnover packages that O&M can actually use.

For teams that want standardized builds and faster handoff, REIG also supports deployments with commissioning-ready hardware/enclosures and configurations through RenergyWare.

Conclusion: hit COD with data you can defend

Solar DAS commissioning goes faster when targets are explicit: completeness (the right points and documentation), accuracy (device-to-historian truth), and latency (data arrives with the timing your team needs). When you scope to evidence instead of screenshots, COD becomes a controlled finish and O&M inherits a system they can trust.

If you’re approaching commissioning (or cleaning up unreliable data after turnover), start by freezing a testable point list, validating time sync, proving device-to-historian accuracy on critical points, and measuring latency against real operational use cases.

Further reading: Solar Plant SCADA System: Reference Architecture in One Diagram | Solar SCADA commissioning to COD: timeline and milestones | Solar DAS sensor map and data flow