IEC 61850 Quality Flags and Their Mapping to SCADA Protocols

A quality-first mapping guide covering q attributes, quality-change events, target-protocol limitations, HMI display, control gating and fault injection.

The IEC 61850 quality attribute tells a client whether and how a value may be trusted. If a gateway forwards only the value and drops quality, a failed input, test injection, substituted value or stale communication can appear as a healthy breaker state. Quality therefore belongs in the point definition, event logic, HMI and control permissives.

This guide explains the practical IEC 61850 quality structure and its mapping to IEC 60870-5-104, DNP3 and Modbus without assuming that the protocols have identical flag sets.

1. Quality is separate from the value

An IEC 61850 data object commonly contains a value attribute, quality attribute q and timestamp t according to its common data class. A breaker position can remain “closed” as last known value while quality becomes invalid after communication/input failure. HMI should retain context but visibly prevent the value being interpreted as live healthy state.

2. Validity

ValidityOperational interpretation
GoodValue is valid subject to any source/test/substitution qualifiers
InvalidValue cannot be used as valid process state
QuestionableValue may be usable with caution under project policy
ReservedDo not assign a local meaning; handle per standard/profile

“Good” does not necessarily mean live production data if test or substituted is set. Always evaluate the complete quality attribute.

3. Detail quality flags

  • Overflow: value exceeded the representable/calculation range.
  • Out of range: value is outside a defined valid range.
  • Bad reference: reference/calibration source is invalid.
  • Oscillatory: unstable/changing in a manner identified by the source.
  • Failure: supervision detected a failure affecting the value.
  • Old data: update/freshness condition is not satisfied.
  • Applicability and combination depend on the data class/device implementation; test the actual model.

4. Source and operator qualifiers

  • Substituted: value is replaced rather than obtained from the normal source.
  • Test: value/message belongs to a test context and must not be mistaken for live production.
  • Operator blocked: further update from the source has been blocked according to the model/operation.
  • Keep substitution/test/block identity and audit at the source/system.
  • Do not clear these qualifiers at the gateway because the numeric state looks plausible.
  • Make them prominent wherever the point could influence operation or analysis.

5. Quality change is an event

  • Configure report quality-change triggering where supported/applicable.
  • A breaker value that remains closed but becomes invalid must update HMI/control center.
  • Preserve reason-for-inclusion/target event meaning when converting protocols.
  • Avoid deadband suppressing quality changes on analog values.
  • Test quality deterioration and restoration with no value change.
  • Use integrity/general interrogation to reconcile state after reconnect, not as the only quality mechanism.

6. Mapping to IEC 60870-5-104

IEC 104 information objects carry quality descriptors appropriate to their type, but their bit set is not identical to IEC 61850 quality. IEC TS 61850-80-1 provides the principal IEC guidance for mapping CDC-based data to IEC 101/104. The project profile must define validity, overflow, blocked, substituted/not-topical and time-quality behavior without inventing false equivalence.

  • Map per target type (single/double point, measured value, counter), not one universal byte.
  • Preserve invalid and overflow wherever target descriptors support them.
  • Define precedence when multiple IEC 61850 details collapse to one target flag.
  • Provide companion diagnostic/event for unmappable test/substitution detail if operationally required.
  • Keep source IED failure distinct from gateway/master-link failure.
  • Test time-tag/quality and interrogation/restoration together.

7. Mapping to DNP3

DNP3 object flags provide online/restart/communication-lost/remote-forced/local-forced/over-range and other type-dependent information, but again there is no universal one-to-one map. Use the exact object/variation/profile and distinguish gateway-forced state from source substitution where possible.

  • Set ONLINE only when the canonical source quality and freshness policy permits.
  • Map forced/substituted state with source clarity and audit.
  • Use COMM_LOST/restart semantics according to where the failure occurred.
  • Map over-range for analog/counter types without losing invalidity.
  • Generate a DNP event when relevant quality changes.
  • Document every unsupported IEC 61850 flag in the device/gateway profile.

8. Mapping to Modbus

Traditional Modbus registers do not carry a standard substation quality attribute. A gateway must add a companion status register/bitmask, a defined communication-state convention or restrict Modbus to use cases where quality loss is formally acceptable. A timeout at the Modbus client detects link failure but not necessarily stale or substituted source data inside the server.

  • Freeze the companion quality-register layout and bit meanings.
  • Update value and quality atomically or provide a sequence/version register.
  • Define stale timer and server/client link-failure behavior.
  • Never encode “bad” by writing zero to the process value.
  • Use read-only monitoring for lower-criticality auxiliaries where full semantics are unavailable.
  • Test word order/bit mask plus all quality transitions.

9. HMI and alarm behavior

  • Use consistent symbols/colors/patterns for invalid, questionable, stale, test and substituted states.
  • Retain last value for context but make degraded quality impossible to overlook.
  • Show the reason/source of bad quality on drill-down.
  • Alarm the actionable root cause, not every child point, while preserving each point’s bad quality.
  • Do not allow acknowledgment to make the value appear healthy.
  • For historian/trends, store quality with each sample and mark gaps/substitution.

10. Controls and automation

  • Remote close should normally require fresh, valid topology/position and correct authority.
  • Define whether questionable data may be used by each function; do not use one global rule.
  • Test/substituted values should not drive production automation unless explicitly isolated and authorized.
  • Protection fallback must be local and documented; SCADA quality is not a protection trip signal by default.
  • Revalidate process state after communication restoration before re-enabling commands.
  • Return specific rejection reason when bad quality blocks a command.

11. Mapping matrix and precedence

Source qualityCanonical resultTarget/fallbackHMI/control rule
Invalid + failureInvalid, cause failureTarget invalid plus diagnosticBad display; block dependent close
Good + testValid test valueTest flag or companion pointProminent test; isolate production use
Good + substitutedValid substituted valueSubstituted/forced mappingShow/audit; use by policy
Questionable + old dataDegraded/staleTarget degraded/invalid per profileStale display; control rule
OverflowValue not quantitatively reliableOverflow/out-of-rangeAlarm/use limits; no healthy clipping

12. FAT/SAT

  1. Freeze IEC 61850 model, report triggers, gateway map and target protocol profile.
  2. Inject every supported validity/detail/source/operator quality flag and combinations.
  3. Change quality without value and verify report/event through every layer.
  4. Test IED restart/link loss, gateway loss, WAN loss and stale timer separately.
  5. Apply test/simulation/substitution/operator block and verify HMI, historian and control isolation.
  6. Test analog overflow/out-of-range and breaker invalid/intermediate state.
  7. Restore communication and confirm quality returns only after revalidation.
  8. Attempt controls/automation with each degraded quality and verify the approved rule.
  9. Review packet captures and database entries against the mapping matrix.
  10. At SAT, prove physical input failure and real control-center presentation.

References and further reading

Engineering note: Never translate an unsupported quality state to “good”; preserve it, expose a diagnostic companion indication or formally restrict the use case.

LearnSwitchgear

Search the engineering library