IEC 61850 Data Object vs Data Attribute

Back to Blog

Nesting From Node to Value

A logical node is not a flat list of numbers; it contains structured data objects. An XCBR breaker node has a Pos data object for position, an OpCnt data object for the operation counter, and so on. Each data object is an instance of a common data class (CDC) - a reusable template defined by the standard. The Pos object uses the controllable-double-point class; a measured current uses a measured-value class. The CDC is what makes the internal structure predictable across devices.

Inside each data object are data attributes: the individual fields. The pattern repeats everywhere. A status data object typically carries stVal (the status value itself), q (a quality field flagging validity, and whether the value is good, questionable, or invalid), and t (the timestamp of the last change). A measured value carries mag (magnitude), q, and t. Reading q and t alongside the value is essential - a value with bad quality should not be trusted no matter what stVal says.

Building the Full Reference

The full object reference walks the whole hierarchy: IED name, then logical device, then logical node, then data object, then data attribute. A reference to a breaker's status value might read as the logical device, XCBR node, Pos object, and stVal attribute joined by dots and a slash. That precise path is what a client subscribes to and what appears in a dataset.

This is also why datasets and reporting are built from the SCL file rather than by hand - the exact data-object and data-attribute names come from the model. When you configure a report control block, you are choosing which of these attributes go into the report and which trigger it. The nesting is the concrete detail beneath the abstract model in the IEC 61850 series structure.

Functional Constraints Group the Attributes

Look inside any data object with a browsing client and you will see more attributes than stVal, q, and t. The standard sorts them with a functional constraint (FC), a tag that says what role each attribute plays. ST marks status attributes, MX marks measurands, CO marks control attributes such as Oper and SBOw, CF marks configuration such as ctlModel, DC marks descriptions, and SP marks setpoints. The same Pos data object therefore carries its live position under ST, its control entry points under CO, and its behavioral configuration under CF, all side by side in one object.

The grouping is not cosmetic. Services address attributes by functional constraint - a report dataset built for status references ST attributes, a control operation targets CO - and a client that ignores the FC will try to write read-only status values or subscribe to configuration that never changes. When a reference is written out in full, the FC rides along in brackets, which is how attributes with similar names in different roles stay unambiguous.

Common Data Classes You Will Meet First

A handful of common data classes covers most of what a SCADA integration ever touches:

CDC	Kind of data	Core attributes
SPS	Single-point status (boolean indication)	stVal, q, t
DPS	Double-point status (open/closed with intermediate and bad states)	stVal, q, t
DPC	Controllable double point (switchgear position with control)	stVal, q, t plus control attributes such as Oper
MV	Measured analog value	mag, q, t
INS	Integer status (counters, mode words)	stVal, q, t

The pattern is deliberately repetitive: whatever the class, expect one value attribute accompanied by q and t. Once you have mapped one MV and one DPC correctly, the next hundred follow the same shape. Which classes a given device actually implements is declared in its SCL capability files, which is where mapping work should start - not in a live browse of a device on the bench.

Flattening References Into SCADA Tags

Gateways and SCADA drivers ultimately turn each subscribed data attribute into a flat tag, and the naming decision deserves more care than it usually gets. Encoding the whole path - device, node, object, attribute - into the tag name keeps the mapping self-documenting but produces long names; abbreviating loses the traceability that makes the self-describing model valuable in the first place. Whichever convention is chosen, it should be generated mechanically from the SCL export rather than typed by hand, because a transposed character in one of hundreds of near-identical references is exactly the kind of error commissioning tests miss.

Two mapping rules save later grief. First, carry q through to the SCADA side as a paired quality tag or a quality-stamped value rather than dropping it, so bad or questionable measurements are visibly bad downstream instead of silently plausible. Second, prefer the device's t timestamp over the gateway's arrival time when historizing, so the stored record reflects when things changed at the source rather than when they happened to be delivered.

Debugging a Bad Value Through Its Path

When a value in the SCADA looks wrong, its object reference is a debugging map. Walk it segment by segment: is the IED name the device you think it is; is the logical device prefix the right function partition; is the node instance correct - XCBR1 versus XCBR2 matters in a two-breaker bay; is the data object the one intended, Pos rather than a neighboring object; is the attribute and its FC right, stVal under ST rather than a configuration attribute under CF. One wrong segment anywhere in that chain produces a plausible-looking value from the wrong place, which is the hardest class of error to spot from the HMI alone.

Then check q before arguing about the number: a value flagged questionable or invalid is telling you the device itself does not vouch for it, and the fix lives at the device or its wiring, not in the mapping. Comparing the failing reference against the SCL export settles whether the configured path ever matched the engineered one - disagreement between the two is a configuration-management problem masquerading as a data problem.

Frequently Asked Questions