What Is an IEC 61850 Functional Constraint?
Browsing an IEC 61850 model you meet two-letter tags like ST, MX, CF, and SP attached to data, and they change what you can do with an attribute. Those are functional constraints. This page explains what a functional constraint is, the common ones you will see, and why they organize access to the data model.
Functional Constraint in one line: A functional constraint (FC) is a two-letter tag that groups IEC 61850 data attributes by their role rather than by where they sit in the object tree. Common ones are ST (status), MX (measured/analog), CF (configuration), SP (setpoint), and DC (description). A functionally constrained data reference selects only the attributes of one FC, which is how clients read status separately from settings.
Organizing Data by Role, Not Just Position
A single data object can hold attributes with very different purposes: the live status value, its quality and timestamp, its configuration, and a description. IEC 61850 tags each attribute with a functional constraint so a client can address a slice of the object by role. ST gathers the status attributes (like stVal, q, t), MX gathers measured analog values, CF gathers the configuration that shapes how a value is produced, SP gathers setpoints, and DC gathers description text. The FC is orthogonal to the object hierarchy - it cuts across it.
This matters because different roles have different access rules and update behavior. Status (ST) data changes with the process and drives reports; configuration (CF) changes rarely and is written deliberately; setpoints (SP) are operator-controlled values. By selecting an FC, a client reads or writes only the attributes appropriate to what it is doing, instead of pulling an entire object when it only wants the live status.
Why Functional Constraints Show Up in Practice
When you build a dataset or a report, you reference functionally constrained data - a data object plus the FC that picks the attributes you want in the message. A status dataset pulls ST attributes; a measurement dataset pulls MX attributes. Choosing the right FC keeps the message focused on what actually needs to be reported.
Functional constraints also show up in browsing tools and SCL, where you will see the FC attached to each data attribute. Recognizing that ST means live status and CF means configuration saves confusion when a value you expected to change sits still - it may be a CF attribute, not the ST one. The FC is a small but load-bearing piece of the IEC 61850 access model.
The Wider FC Alphabet
ST, MX, CF, SP, and DC cover most of what you meet, but the model defines more roles, and several matter in daily work. CO groups the control attributes a client operates through the command services - select, operate, cancel - rather than plain writes. SV covers substitution, the mechanism for forcing a replacement value to stand in for the live one. SG and SE both deal with setting groups: SG addresses the active group's values, SE the group currently being edited. And the reporting machinery has its own constraints - BR for buffered report control blocks, RP for unbuffered ones, GO for GOOSE control blocks - because control blocks are themselves addressable objects with attributes of their own.
| FC | What it groups |
|---|---|
| CO | Control attributes operated through command services |
| SV | Substitution values that stand in for the live process value |
| SG / SE | Setting groups: the active group vs the one being edited |
| BR / RP | Buffered and unbuffered report control blocks |
| GO | GOOSE control blocks |
You rarely configure most of these by hand, but recognizing them keeps a browsing session coherent: when a client tool shows the same data object several times under different FCs, it is showing you the object's different conversations, not duplicate points.
A Worked Example: One Breaker, Several FCs
Consider a breaker position at the symbolic path Feeder1/XCBR1.Pos, where XCBR1 is the breaker logical node. Ask for Pos with ST and you receive stVal, q, and t - the live position with its quality and timestamp, which is what an HMI or a report wants. Ask with CF and you receive configuration such as ctlModel, which declares how the breaker may be commanded, for example direct operate versus select-before-operate. Ask with CO and you are addressing the control structures a client writes through the command services to actually open or close it. Ask with DC and you get description text for documentation. One object, four different purposes, chosen entirely by the functional constraint.
This is also where the FCD versus FCDA distinction earns its keep. A functionally constrained data reference (FCD) names the object plus an FC and expands to every matching attribute: Pos with ST brings stVal, q, and t along together. An FCDA narrows all the way to a single attribute. Report and GOOSE members are built from these references, and that expansion explains why one member entry can produce several values in the resulting message.
Symptoms That Trace Back to the FC
A handful of everyday mysteries dissolve once you think in FCs. A write is refused: attributes under ST and MX are owned by the process and are read-only by design, and commanding equipment through a plain write instead of the CO control services fails on purpose. A trend that never moves may be subscribed to the configuration slice rather than the live one - re-check the FC in the reference before blaming the device. A value that moves but disagrees with the field deserves a look at its quality attribute, because a substituted value entered through SV stops following the process until the substitution is cleared.
Setting groups produce their own confusion: edits made through SE take effect only when the edited group is activated, while SG shows what is currently live, so compare the two before concluding a relay ignored its new settings. And when reports stop arriving, remember the report control block is its own object with enable and trigger attributes under BR or RP - the fault is often there, not in the data being reported. The FC tells you which conversation to debug.
Reading FCs in SCL
In SCL files, the FC appears in the data type templates, so a device's capability description declares once which attributes carry which constraint and every instance inherits it. When a dataset is defined in SCL, each member entry carries its FC explicitly. If you are comparing a running device against its engineering file, this is where to confirm that a member really references the ST slice you expect rather than an attribute from a different role - a quiet mismatch here produces reports that are syntactically valid and operationally useless.
Frequently Asked Questions
What do ST, MX, CF and SP mean in IEC 61850?
They are functional constraints tagging attributes by role: ST is status data, MX is measured analog values, CF is configuration, and SP is setpoints. Selecting an FC lets a client read or write only the attributes that fit what it is doing.
Why not just address data attributes directly?
You can, but the functional constraint lets you select a role-based slice of an object in one reference - all the status attributes, or all the configuration - which is what datasets and reports need. It groups attributes by purpose across the object structure.
Where do I see functional constraints?
In SCL files, in browsing tools that display the model, and in functionally constrained data references used to build datasets and reports. Each data attribute carries an FC tag indicating its role, such as ST for status or CF for configuration.
Why does writing to a status value fail in IEC 61850?
Because attributes under the ST and MX functional constraints belong to the process and are read-only. Commands must go through the control services addressed by the CO constraint, and forced values must use the substitution mechanism under SV. The refusal is the data model working as intended, not a fault.
What does it mean when a value is substituted?
Someone used the SV functional constraint to force a replacement value that stands in for the live measurement, typically during maintenance or a sensor failure. The quality attribute flags the value as substituted, and it will not track the process again until the substitution is cleared.
Automation services
Need help turning this into a working system?
Merobix integrates SCADA, programs Allen-Bradley and Siemens PLCs, and designs and fabricates industrial control panels.
Meeting requests are reviewed before confirmation.