Data Sets are one of the most important concepts in IEC 61850. They define which values inside an IED are grouped together so the device can report them, log them, publish them over GOOSE, or return them in a single MMS read request.
Anyone working with protection relays, SCADA integration, automation logic, or commissioning eventually deals with Data Sets. Understanding how they work removes a lot of confusion when configuring reporting, GOOSE, or gateway mapping.
IEC 61850 supports two flexible Data Set mechanisms:
- Static Data Sets
- Dynamic Data Sets
Both are valid, but they behave very differently.
This article explains how each type works, why the standard defines them, and how they are used inside real substations.
Table of Contents
What Is a Data Set in IEC 61850?
A Data Set is a collection of references to Data Objects or Data Attributes inside an IED.
These references can come from:
- different Logical Devices
- different Logical Nodes
- different Data Objects
- different functional constraints (ST, MX, CO, SP, etc.)
- different instances altogether
A Data Set does not contain the values themselves.
Instead, it contains pointers to the values inside the IED’s data model.
When the Data Set is used by a Report Control Block, Log Control Block, or GOOSE Control Block, the IED collects all the referenced values and sends them together. This makes Data Sets a flexible and powerful mechanism for data grouping.
Why Data Sets Exist
IEC 61850 uses Data Sets to define exactly which data elements an IED should group together for communication and monitoring. Different IEC 61850 services rely on these groups to know which values they must handle. Examples include:
- Reports need a defined list of Data Attributes to monitor for changes and transmit to clients.
- GOOSE control blocks require a fixed set of members to publish in each message.
- Log control blocks use Data Sets to determine which Data Objects or Data Attributes should be recorded.
- Engineering tools use Data Sets to read related values efficiently in a single operation.
- Diagnostic or commissioning tools create temporary Data Sets to observe specific points during testing.
Without Data Sets, every service—reporting, logging, GOOSE, and engineering—would require its own separate configuration of data members. This would increase complexity and make consistent, interoperable behavior across devices much harder to achieve.
Types of Data Sets in IEC 61850
IEC 61850 defines two categories of Data Sets, each designed for a different purpose inside the IED:
- Static Data Sets – predefined in the SCL configuration and permanently stored in the device.
- Dynamic Data Sets – created by a client at runtime for temporary or engineering-related tasks.
Both types follow the same Data Set structure, but their lifetime, usage, and behavior are very different.
Static Data Sets
Static Data Sets are defined in SCL (ICD, CID, SCD) and loaded automatically when the IED starts. They are part of the permanent device model and exist independently of any MMS client connection.
Defined in SCL
It is defined using the <DataSet> element within a Logical Node.
Because it is part of the engineered SCL model, the Data Set becomes a permanent object inside the IED.
Once the device powers up, Static Data Sets are loaded immediately from configuration and are available before any MMS client establishes an association.
Permanent and Persistent
Static Data Sets remain intact across all normal device operations. They persist through:
- IED reboot
- configuration reload
- SCADA or client disconnection
- loss of MMS association
- client failover
This stability is critical for protection and automation functions.
Used for Critical Functions
Static Data Sets are required by IEC 61850 for:
- Buffered Report Control Blocks (BRCB)
- Unbuffered Report Control Blocks (URCB)
- Log Control Blocks (LCB)
- GOOSE Control Blocks
- Permanent log data sets
- Any fixed, operationally required data grouping
Protection, automation, and SCADA systems rely on consistency.
For this reason:
- A GOOSE Control Block cannot reference a Dynamic Data Set.
- A Report Control Block will not operate if its referenced Data Set is missing or altered.
Static Data Sets ensure the message structure remains predictable and compliant with engineering design.
Cannot Be Modified by Clients
Static Data Sets are fully read-only during runtime.
Clients—whether SCADA, gateways, or engineering tools—cannot:
- add Data Set members
- remove Data Set members
- reorder or change the Data Set content
This design prevents accidental or unauthorized changes that could disturb protection behavior or SCADA reporting.
Visible to All Clients
All connected clients can access information about Static Data Sets, including:
- the Data Set name
- the list of FCD/FCDA elements inside the Data Set
- any Report or Log Control Blocks that reference it
This supports multi-client architectures where different systems—SCADA, historians, redundancy controllers, or engineering tools—need to view or subscribe to the same Data Set structure.
Dynamic Data Sets
Created by Clients at Runtime
A Dynamic Data Set is not defined in the SCL file.
Instead, it is created during a live MMS association by a client such as:
- an engineering tool
- a commissioning tool
- a diagnostic application
- a SCADA system performing temporary operations
The client uses the CreateDataSet service to define:
- the Data Set name
- the list of members (FCD or FCDA references)
Once created, the Dynamic Data Set exists only inside the active client–server association.
Association-Specific
Dynamic Data Sets are private to the MMS session that created them.
Other clients cannot see, access, or use them.
The Data Set belongs exclusively to:
- that connection
- that IP session
- that authentication context
This ensures that temporary engineering operations do not interfere with other live systems.
Non-persistent Dynamic Data Sets
These Data Sets exist only for the active MMS association that created them.
They are deleted when the client disconnects, when the session expires, or when the IED restarts.
Because they are temporary and not guaranteed to exist at device startup, non-persistent Dynamic Data Sets cannot be used by:
- Buffered Report Control Blocks (BRCB)
- GOOSE Control Blocks (GoCB)
- Log Control Blocks (LCB)
Non-persistent Dynamic Data Sets are allowed only for URCB and USVCB, where the client is expected to manage them during the session.
Persistent Dynamic Data Sets
Persistent Dynamic Data Sets are created at runtime but stored inside the IED until explicitly deleted.
They remain valid regardless of MMS connections and may be referenced by control blocks.
Persistent Dynamic Data Sets can be used by:
- URCB
- BRCB
- GoCB
- LCB
- Other control classes that require stable Data Set references
Operational Consequences
Because non-persistent Data Sets exist only during a client session, they are not suitable for operational functions that must survive:
- reboot
- failover
- client handover
- network reconnection
Therefore, non-persistent Dynamic Data Sets are not used for:
- protection trip messaging
- breaker status reporting
- alarm and event reporting
- interlocking GOOSE signals
- asset monitoring
- routine SCADA updates
Persistent Dynamic Data Sets may support these functions if the IED manufacturer implements them, but in practice many utilities still prefer Static Data Sets for all critical operations because they provide deterministic behavior.
Dynamic Data Set Creation and Visibility
The figure below illustrates how IEC 61850 supports both persistent and non-persistent dynamic Data Sets. Persistent Data Sets remain in the server and may be used by any control block, while non-persistent Data Sets exist only for the active association and shall only be used by URCB or USVCB.
How Data Sets Are Represented Internally
IEC 61850 Data Sets do not store values themselves.
Instead, each entry in a Data Set is a reference to an element in the IED’s data model.
These references allow the server to collect the correct values whenever the Data Set is used for reporting, logging, GOOSE messaging, or MMS read services.
The standard defines two referencing formats inside a Data Set: FCD and FCDA.
FCD and FCDA
FCD — Functionally Constrained Data
An FCD refers to a complete Data Object under a specific functional constraint.
Example:
MMXU1.A.phsA
This means:
- Logical Node = MMXU1
- Data Object = A
- Sub-component = phsA
- Functional Constraint typically MX (measured) or ST (status), depending on context
An FCD entry causes the Data Set to include all Data Attributes of that Data Object under the specified constraint.
This is useful when the client needs the entire structure.
FCDA — Functionally Constrained Data Attribute
An FCDA points to a single, specific Data Attribute.
Example:
MMXU1.A.phsA.instMag.f
This means the Data Set includes only the f attribute (e.g., frequency or magnitude component) of that measurement.
An FCDA gives exact control over which values are included.
When to Use Each
- FCD is used when the application needs all attributes of a Data Object for a given functional constraint.
- FCDA is used when only specific attributes should be included—useful for GOOSE messages or precise reporting.
Both formats allow Data Sets to be optimized for performance, bandwidth, and application needs.
Data Across Logical Nodes
IEC 61850 places no restriction on where Data Set members may come from.
A single Data Set can gather data from any part of the IED’s data model, which makes the mechanism extremely flexible.
A Data Set may include members from:
Multiple Logical Nodes
Examples:
MMXU1(measurements)XCBR1(breaker control)PTRC1(protection trip)PDIS1(distance protection)RREC1(reclosing)
This allows DataSets to represent complete operational contexts.
Multiple Logical Devices
For multi-processor or multi-function IEDs, Data Sets may span:
- LD1 (Protection)
- LD2 (Metering)
- LD3 (Automation)
This enables advanced reporting and GOOSE messages that combine information across independent subsystems.
Multiple Functional Constraints
Entries in a Data Set may include Data Attributes from different constraints:
- ST (status)
- MX (measurement)
- CO (control)
- SP (setpoint)
- CF (configuration)
- SV (substitution)
- SG (setting groups)
This allows a single Data Set to mix binary status values, analog measurements, configuration points, and more.
Mixed Analog and Status Values
Data Sets may combine:
- Analog values (e.g.,
instMag,cVal,rmx,rms) - Binary status values (e.g.,
stVal,q) - Protection outputs (e.g.,
Op.stVal) - Supervision signals
- Quality flags
- Timestamps
This flexibility supports complex reporting and control logic.
Protection-Related Signals
Protection IEDs commonly include:
- Trip outputs
- Operate signals
- Pickup statuses
- Timer values
- Zone results (Z1, Z2, Z3)
- Interlocking conditions
- Auto-reclose states
These can all be combined naturally into Data Sets used for event reporting and automation.
Custom or Vendor-Specific Data Objects
IEC 61850 permits:
- Manufacturer-specific Logical Nodes (
LnNs = ‘LLN0’ or Private LN classes) - Custom Data Objects
- Proprietary measurement or diagnostic attributes
These can also appear in Data Sets.
Data Sets operate on references, not values.
By using FCD and FCDA formats, they can point to either full Data Objects or individual Data Attributes.
Because any element of the data model may be included, Data Sets can combine values across Logical Nodes, Logical Devices, functional constraints, and even custom structures.
This makes Data Sets one of the most flexible and powerful tools in IEC 61850.
Mapping Data Sets to MMS
In IEC 61850, all communication with clients is done using MMS (Manufacturing Message Specification). To make the object-oriented IEC 61850 data model compatible with MMS, the standard defines how Data Sets are translated into MMS structures.
When an IED exposes a Data Set to a client—whether static, persistent dynamic, or non-persistent dynamic—it becomes an MMS NamedVariableList.
This mapping is one of the core parts of IEC 61850-8-1.
Data Set → MMS NamedVariableList
Every Data Set in the IED maps directly to a NamedVariableList object in MMS.
Key points
- The Data Set name becomes the MMS list name.
- Each FCD or FCDA entry becomes an individual variable reference inside the list.
- The structure of the Data Set in MMS mirrors the structure defined in the IED.
- MMS takes care of transporting the values when a service requests them.
This mapping allows MMS clients to:
- read the Data Set values
- access the Data Set structure
- link the Data Set to report control blocks
- perform batch retrieval through GetDataSetValues
Static vs Dynamic Data Sets in MMS
In MMS, both types of Data Sets appear as NamedVariableLists, but their lifetime and visibility differ.
Static Data Sets → Persistent NamedVariableLists
- Loaded from SCL during startup
- Visible to all clients
- Exist permanently in the server
- Can be referenced by RCBs, LCBs, and GoCBs
Dynamic Data Sets → Association-Specific NamedVariableLists
- Created by the client during the MMS session
- Exist only for that client
- Deleted automatically when the session ends (unless marked persistent)
- Not visible to other clients
This reflects the IEC 61850 requirement that engineering tasks must not interfere with live SCADA or protection operation.
How MMS Reads Data Sets
MMS provides a dedicated service:
GetDataSetValues
When called, the IED collects all the data elements referenced by the Data Set (FCD/FCDA) and returns their values in order.
This is efficient because:
- one MMS request retrieves everything in the Data Set
- no need to read each attribute individually
- the server ensures a consistent timestamp and quality set
How MMS Updates Reports and GOOSE
When a Data Set is linked to a control block, MMS uses the NamedVariableList to determine:
- which values to monitor for data change
- which values to include in a report
- which Data Attributes form the GOOSE payload
- how the dataset should be encoded in the MMS PDU
For example:
Reports (RCBs)
- MMS monitors all Data Set members for triggers:
- data-change (dchg)
- quality-change (qchg)
- data-update (dupd)
- When a trigger occurs, the Data Set values are collected and transmitted through MMS report services.
The figure below illustrates how a BRCB monitors a Static Data Set, evaluates trigger conditions (data-change, quality-change, data-update, general-interrogation, integrity), and sends reports to the client with sequence numbers and timestamps.
GOOSE (GoCB)
- GOOSE messages carry the Data Set values in a fast, Ethernet-based multicast frame.
- The same Data Set structure is used to create the GOOSE payload.
GOOSE Publisher–Subscriber Model
The figure below illustrates how a GOOSE publisher gathers Data Set members (FCD/FCDA), builds the GOOSE payload, and transmits it through Ethernet multicast. The subscriber receives the message, buffers it, and updates its internal data based on the selected Data Set structure and GoCB configuration.
Order of Members Matters
MMS preserves the Data Set member order defined in SCL or during creation.
This is important because:
- GOOSE payloads depend on strict member ordering
- Report clients expect matching sequence structures
- Historians and SCADA parsers rely on deterministic ordering
If the order changes, compatibility with existing subscribers may break.
Example: Data Set Member Ordering and Report Content
The figure below shows how different Data Sets contain different FCD/FCDA members and how member order determines the final structure and content of the reports. Only the Data Attributes that change trigger reporting, but the Data Set ordering defines how values appear in the report payload.
Data Set Mapping and Functional Constraints
Because FCD and FCDA entries include functional constraints (ST, MX, CO, SP, etc.), MMS must map each element to the correct MMS domain and variable.
MMS uses:
- Domains → Logical Devices
- NamedVariables → Logical Nodes
- NamedVariableLists → Data Sets
This ensures every Data Set entry points to a precise MMS-accessible element.
Summary of MMS Mapping Rules
| IEC 61850 Concept | MMS Representation |
|---|---|
| Data Set | NamedVariableList |
| FCD Member | NamedVariable (Structured variable) |
| FCDA Member | NamedVariable (Simple variable) |
| Static DataSet | Persistent NamedVariableList |
| Dynamic Data Set (non-persistent) | Association-specific NamedVariableList |
| Dynamic Data Set (persistent) | Permanent NamedVariableList until deleted |
Comparison of Static, Persistent Dynamic, and Non-Persistent Dynamic Data Sets
IEC 61850 defines three practical Data Set behaviors inside an IED.
Although all three use the same format (lists of FCD/FCDA entries), their lifetime, usage, and restrictions are very different.
This comparison summarizes the exact characteristics of each type.
High-Level Overview
| Feature | Static Data Set | Persistent Dynamic Data Set | Non-Persistent Dynamic Data Set |
|---|---|---|---|
| Defined In | SCL (ICD/CID/SCD) | Created by client, stored in IED | Created by client, lives in client session |
| Lifetime | Permanent | Permanent until deleted | Temporary, deleted on disconnect |
| Survives IED Reboot | Yes | Yes | No |
| Visible to All Clients | Yes | Yes | No |
| Referencable by URCB | Yes | Yes | Yes |
| Referencable by BRCB | Yes | Yes | No |
| Referencable by GoCB | Yes | Yes | No |
| Referencable by LCB | Yes | Yes | No |
| Editable by Clients | No | Yes | Yes |
| Safe for Protection | Yes | Yes | No |
| Typical Purpose | SCADA, protection, GOOSE, logs | Long-term engineering, custom grouping | Testing, commissioning, diagnostics |
Summary Table for Engineering Decisions
| Use Case | Best Data Set Type | Reason |
|---|---|---|
| Protection trip reporting | Static | Most stable and deterministic |
| GOOSE interlocking | Static | Fixed payload required |
| SOE logging | Static | Must survive reboot |
| Long-term custom SCADA grouping | Persistent Dynamic | Stable but flexible |
| Gateway harmonization | Persistent Dynamic | Works across vendors |
| Commissioning tests | Non-Persistent Dynamic | Temporary and safe |
| Protection testing | Non-Persistent Dynamic | Full flexibility |
| Diagnostics | Non-Persistent Dynamic | Ad-hoc grouping |
| Trend analysis | Non-Persistent Dynamic | Created on demand |
Final Summary
- Static Data Sets → For operational and protection-grade functions.
- Persistent dynamic Data Sets → For stable but flexible engineering or gateway-driven structures.
- Non-persistent dynamic Data Sets → For temporary engineering, testing, and diagnostics.
Together, these mechanisms allow IEC 61850 systems to achieve both deterministic reliability and engineering-level flexibility, which is essential for modern substation design, automation, and maintenance.
Conclusion
Data Sets are one of the most important mechanisms in IEC 61850 because they define how information inside an IED is grouped, accessed, reported, and exchanged with other devices. Understanding how Static, Persistent Dynamic, and Non-Persistent Dynamic Data Sets work is essential for designing reliable, interoperable, and safe digital substations.
Static Data Sets form the foundation for all protection, automation, and SCADA functions. Their predictable and permanent structure ensures that reporting, logging, and GOOSE messaging behave the same way after every reboot, failover, or network event. Persistent Dynamic Data Sets add flexibility without compromising stability, allowing long-term custom grouping for gateways, utilities, and engineering applications. Non-Persistent Dynamic Data Sets provide engineers with complete freedom during commissioning, diagnostics, and testing, without affecting the operational model of the IED.
By supporting these three models, IEC 61850 delivers both the deterministic behavior required by protection systems and the flexible tooling needed for engineering and maintenance. This balance is what makes IEC 61850 a powerful and future-proof standard for substation automation, system integration, and digital grid development. Understanding Data Set behavior—how they are created, stored, mapped to MMS, and used by control blocks—is key to building IEC 61850 systems that are robust, interoperable, and ready for modern grid requirements.