Field reference for utility scale solar technicians. 8 entries, taken from the FieldWatt app.
Reference notes from FieldWatt, the offline field toolkit for utility scale solar commissioning and O&M technicians. It works with no cell signal, because the sites do not have any.
Get FieldWatt on the App StoreIgnition by Inductive Automation is the dominant SCADA platform at US solar plants. The architecture in one breath: a central gateway server runs device connections (drivers for Modbus, DNP3, Allen Bradley, OPC UA and more), which feed tags, which feed the historian and the operator screens (Vision or Perspective). Everything a technician sees on a screen traces back through tag, then device connection, then network, then field device; troubleshoot in that order from the gateway web page (Status section shows device connection health and tag counts).
Site Ignition versions and module sets vary; verify against the site system documentation.
Every Ignition tag carries a value, a timestamp, and a quality. Good quality means the driver read the point recently. Bad or Bad_NotConnected means the device connection is down. Stale means the subscription stopped updating. Uncertain often means the device answered with a flagged or substituted value. Quality propagates: one dead device connection turns every tag under it bad at the same moment, which is the signature to look for. A single bad tag among good siblings on the same device points at that one register or address, not at the network.
Quality names vary slightly across Ignition versions.
Ignition talks to many PLCs through OPC UA, either its own internal server fronting the native drivers or an external OPC UA server. A faulted OPC UA connection shows every downstream tag bad while the underlying PLC is fine; the gateway Status page distinguishes the OPC connection state from the device state. Certificate expiry is the classic silent killer: OPC UA connections authenticate with certificates that expire years after commissioning, taking the connection down on a seemingly random day.
Check OPC UA certificate validity dates during annual maintenance.
The tag historian stores tag values in a database for trends and reports. Gaps in trends mean either the tag went bad quality (comms problem) or the historian pipeline stalled (database disk full, database connection down, store and forward buffering). Store and forward matters in the field: when the database link drops, the gateway buffers history and backfills later, so a trend that fills itself in hours later indicates a database side problem, not a field problem.
Database disk space is the first check for plant wide historian gaps.
A stale or bad tag is almost never the SCADA server itself; it is the messenger. The chain, from most to least likely: the field device stopped answering (power, fault, address change); the network path broke (fiber, media converter, switch); the polling configuration flags a slow but healthy device as timed out; the device connection in SCADA is misconfigured after a device swap; or the tag itself points at a register that no longer exists in new firmware. Correlation is the diagnostic tool: all tags on one device bad means the device or its path; all devices on one segment bad means network; scattered single tags bad means register map drift.
Check the timestamp of last good value; it usually marks exactly when the field event happened.
At utility owned plants, Emerson Ovation often runs the whole control room: operator graphics, historian, alarm system, and the power plant controller logic in the same redundant DCS. Point quality and alarm behavior follow DCS conventions rather than Ignition conventions, and configuration lives with the site engineering group. For a field technician the working interface is usually the Ovation operator station: point detail displays show quality, scan status, and the controller that owns each point.
Ovation configurations are site specific; work through the site engineering owner.
The flaw in judging a device by its own telemetry is circular: when the channel is down, the thing reporting that the device is fine is the same thing that is broken. Reliable calls come from evidence that travels a different path than the data. Hardwired alarm and fail contacts. Utility substation practice, and worth copying wherever the equipment supports it: the protective relay's alarm or fail contact is wired to a separate I/O device rather than reported over the same protocol as its measurements. Then the dispatch logic becomes explicit. Loss of comms alarm alone means suspect the channel. Loss of comms alarm PLUS an asserted relay fail contact means the device itself is in trouble, and that combination is what sends a technician. Heartbeat counters with dwell. Comm channels commonly carry a heartbeat counter, and the loss of comms alarm asserts only after the counter stalls for a set dwell, on the order of a couple of minutes. That deliberate delay is why a master configured with a tight response timeout flags healthy devices as offline all day while the properly dwelled alarm stays quiet. Protocol level counters. Most protocols expose retry, timeout, and frame error counters that turn a subjective impression into a number. As one example, a DNP3 I/O server may flag points as bad value after roughly three retries. There is no standard: the threshold varies between utilities, vendors, and I/O servers. The transferable practice is to know your own system's retry count and dwell, because that number is what separates a device that is genuinely gone from one that is merely slow. The revenue meter counter test. The cleanest artifact test available, and it needs no site visit. Watch the kWh totalizer on the revenue meter across the outage. If the counter stalls during the gap and then JUMPS when comms restore, the meter kept accumulating the whole time: the equipment was running and only the telemetry was down. If the counter stalls and then resumes counting flat from where it stopped, production genuinely stopped.
Thresholds and dwell times vary by utility, vendor, and I/O server; confirm the values configured on your own system. Contributed by substation practitioners.
The most valuable SCADA skill in solar O&M is telling a real equipment fault from a communications artifact before rolling a truck. Real faults: production actually drops, neighboring measurements corroborate (the meter sees less power, the transformer sees less current), and the device logs a fault locally. Comms artifacts: values freeze or go bad quality while plant output at the meter stays flat, many devices change state at the same timestamp, and the device checks out healthy at its local display. When SCADA and the revenue meter disagree, believe the meter. Better still, do not rely on the telemetry path alone: hardwired fail contacts, protocol retry counters, and the revenue meter counter test give evidence over a different path. See Independent confirmation.
Never reset or cycle field equipment purely because SCADA shows it offline. Confirm at the device first.
Cross check against the revenue meter and neighboring device telemetry.
Reference notes from FieldWatt, the offline field toolkit for utility scale solar commissioning and O&M technicians. It works with no cell signal, because the sites do not have any.
Get FieldWatt on the App StoreThese notes are a field aid, not a substitute for the governing codes, the stamped drawings, the authority having jurisdiction, or manufacturer manuals. Verify against the current documentation for your installed equipment.