IEC 61850 is interoperable because it communicates named functions and data semantics—not because every signal is reduced to a vendor register number. For an MV feeder bay, the data model should identify the breaker, switches, controls, interlocks, protection functions, measurements, instrument transformers and physical device. Poor modeling can still exchange packets, but it creates ambiguous HMI, unsafe subscriptions and configuration that cannot be maintained across vendors.
This guide explains logical devices, logical nodes, data objects, CDCs, attributes, functional constraints and practical MV bay allocation, with protection/control examples, naming, SCL, quality, testing and lifecycle rules.
1. The IEC 61850 model hierarchy
- IED: the physical intelligent electronic device with one or more access points/servers.
- Logical device (LD): an implementation grouping of functions inside an IED.
- Logical node (LN): the smallest standardized functional building block, identified by class, optional prefix and instance.
- Data object (DO): a standardized item within an LN, such as position, operation, measured quantity or health.
- Data attribute (DA): value, quality, timestamp, configuration or control detail within the object.
- Common Data Class (CDC): standardized structure/semantics for a kind of data, such as status, controllable double point or measured value.
A reference is therefore meaningful: it leads from IED/logical device to LN and object/attribute. Dataset members and GOOSE/MMS/SV subscriptions should preserve that meaning through SCL.
2. LN naming rule
An LN name combines an optional functional prefix, a four-character standardized LN class and an instance number. For example, an implementation could use a class XCBR for a circuit breaker with an instance distinguishing multiple breakers. The project naming convention must be stable, unique in its scope and consistent with SCL/process associations.
- Do not encode uncontrolled drawing prose into prefixes.
- Use instances/prefixes to distinguish functions, not to change standardized semantics.
- Keep IED name, logical-device instance and LN naming separate.
- Associate LNs with the correct substation bay/conducting equipment in SCL.
- Publish a naming authority document before multi-vendor ICD/SCD integration.
- Never assume identical LN names in different IEDs refer to the same primary equipment.
3. Core MV switchgear logical nodes
| LN class | Typical function | MV use |
|---|---|---|
| XCBR | Circuit breaker | Breaker position, operations, condition/nameplate-related model data |
| XSWI | Switching device other than circuit breaker | Disconnector, earthing switch or truck-related switching representation as applicable |
| CSWI | Switch controller | Control processing for breaker/switch |
| CILO | Interlocking | Release/permissive logic for safe switching |
| PTRC | Protection trip conditioning | Combine/route protection operations to trip |
| RREC | Autoreclosing | Feeder reclose sequence |
| RBRF | Breaker failure | Failure detection, retrip and upstream trip initiation |
| MMXU | Measurements | Phase/sequence current, voltage, power and frequency as modeled |
Use the current IEC 61850-7-4 edition and the online namespace/schema artifacts supported by the project. A class name does not prescribe an entire protection scheme; it standardizes external visible information for the function.
4. Protection logical nodes
| LN class | Protection concept | Application note |
|---|---|---|
| PTOC / PIOC | Time / instantaneous overcurrent | Use instances/prefixes for phase, earth or stages according to modeling rules |
| PTOV / PTUV | Overvoltage / undervoltage | Coordinate measured input source and stage semantics |
| PDIF | Differential | Feeder/transformer/bus application context must be explicit |
| PDIS | Distance | Zones and settings remain application configuration |
| PDIR | Directional comparison/direction | Often supports directional logic with other functions |
| PFRQ | Frequency protection | Over/under frequency or rate/application configuration |
| PTTR | Thermal overload | Thermal state and trip/alarm behavior |
| PSCH | Protection scheme communication | Teleprotection/permissive/blocking scheme model |
Do not collapse every relay pickup into GGIO merely because it is easy. Use standardized protection LNs/data where supported; use GGIO only for information that genuinely lacks a suitable standardized semantic or for carefully controlled legacy mapping.
5. Instrument transformer and process nodes
- TCTR: current-transformer representation associated with current samples/measurement chain.
- TVTR: voltage-transformer representation.
- GGIO: generic process I/O when no more specific model applies.
- LPHD: physical-device information/health.
- LLN0: common logical-node services and system-level controls within each logical device.
- GSAL: alarm/event-related information where applicable to the implementation.
- Monitoring nodes in IEC 61850-7-4 can represent condition information related to IEC 62271 equipment; select by the actual published model.
6. Value, quality and timestamp
Many status/measured data expose a value with q quality and t timestamp according to their CDC. Subscriber logic and HMI should retain the relationship. A breaker position with invalid quality is not a trustworthy open/closed state; a measurement without time quality may be unsuitable for event correlation.
- Map validity and relevant detail/test/operator-blocked/source states.
- Define timestamp origin: process change, IED detection or client receipt.
- Preserve double-point position semantics for intermediate/bad states.
- Do not reduce quality to a separate unrelated Boolean that clients can ignore.
- Test time/quality behavior through GOOSE, reports and gateways.
- Document substitutions and blocked outputs.
7. Functional constraints
Functional constraints group attributes by purpose—status, measurements, controls, configuration, settings, description and related classes. They are part of object references and dataset selection. Choosing the wrong functional constraint can retrieve a setting/configuration attribute instead of the live status or make a client/subscription incompatible.
- ST: status information.
- MX: measured values.
- CO: control service attributes.
- CF/DC: configuration/description information as modeled.
- SP/SG/SE: setting-related functional constraints according to the data model/service.
- Use the exact IEC data model and ICD/SCD; do not infer from abbreviations alone.
8. Control model: CSWI, CILO and XCBR/XSWI
A typical logical control path is operator/automation command → CSWI control processing → CILO release/interlock → XCBR/XSWI controllable position → process output, with feedback returning from the primary device. Actual implementations can allocate these LNs across devices; the external behavior and subscriptions must remain clear.
- Specify direct versus select-before-operate control and enhanced security behavior.
- Coordinate origin, control number/checking and termination response as supported.
- Require valid interlock/synchrocheck prerequisites and clear rejection reason.
- Use independent position feedback; a command success is not proof of mechanism position.
- Model local/remote, blocked, test and health states.
- Test simultaneous, stale and canceled controls plus client loss.
9. Protection trip path: P-function, PTRC and XCBR
A protection LN asserts operation; PTRC can combine/condition trip outputs; XCBR represents the breaker and its position. GOOSE datasets may publish protection operate/trip or process commands depending on architecture. Keep pickup/start, operate, trip conditioning, breaker command and breaker position as distinct events.
- Map each protection function and stage to the trip matrix.
- Keep breaker-failure start, retrip and backup trip identifiable.
- Model lockout/hand reset with suitable standardized information or controlled extension.
- Preserve quality/test/simulation behavior through the entire path.
- Measure application-to-breaker timing; data model conformance alone proves no performance.
- Record function operation and physical interruption separately.
10. Example MV feeder allocation
| Function group | Example LNs | Key external data |
|---|---|---|
| Common/device | LLN0, LPHD | Mode/behavior, health, nameplate, datasets/control blocks |
| Process | TCTR, TVTR, XCBR, XSWI | Current/voltage source, positions, operation/condition |
| Control/interlock | CSWI, CILO | Control, release, command response |
| Protection | PTOC, PIOC, PDIR, PTUV, PTOV, RBRF | Starts/operations and settings/status |
| Trip/reclose | PTRC, RREC | Trip conditioning and reclose state |
| Measurement | MMXU | Phase/sequence values and quality/time |
This is an allocation example, not a mandatory device template. The vendor ICD, project Basic Application Profile and protection philosophy determine available/required objects and services.
11. SCL engineering
- Import the exact ICD for hardware, firmware, options and IEC 61850 edition.
- Instantiate IED/LD/LN names under the approved naming convention.
- Associate LNs with substation voltage level, bay and conducting equipment.
- Engineer datasets, reports, GOOSE/SV control blocks and ExtRefs.
- Validate DataTypeTemplates and namespace compatibility.
- Use Basic Application Profiles where adopted to standardize function interfaces.
- Run schema, semantic and application validation.
- Generate target CID/device packages and reconcile as-built changes into the SCD.
12. Common modeling errors
| Error | Consequence | Prevention |
|---|---|---|
| Everything mapped to GGIO | Lost semantics and vendor-specific interpretation | Use standardized LN/DO where available |
| Value without quality/time | Stale/invalid state appears healthy | Carry/test CDC semantics |
| Wrong LN instance/prefix | Adjacent function/bay confusion | Naming authority and process association |
| Command treated as position | Mechanism failure hidden | Use independent XCBR/XSWI feedback |
| Schema-valid wrong ExtRef | Unsafe subscription | Application matrix and end-to-end test |
| Vendor model changed with firmware | CID/SCD mismatch | Exact-version ICD and semantic diff |
13. FAT/SAT checklist
- Review every LN/DO against the protection, control and SLD requirements.
- Validate SCL schema, namespace, types and semantic rules.
- Trace every HMI/report/GOOSE/SV member to its physical source/application.
- Operate each breaker/switch/contact and verify value, quality, time and intermediate state.
- Test every protection pickup/operate/trip stage and breaker feedback.
- Test controls, interlock rejection, origin and termination behavior.
- Apply bad quality, test/simulation, communication loss and device restart.
- Compare events/reports at all clients and gateway mappings.
- Verify firmware/tool round trip does not strip or reorder required semantics.
- Archive exact SCD/CIDs/ICDs/settings and evidence as the as-built model.
References and further reading
- IEC 61850-7-4:2010+A1:2020 — Compatible logical-node and data-object classes
- IEC 61850-7-2 consolidated edition — Abstract communication services
- IEC 61850-7-3 consolidated edition — Common data classes
- IEC 61850-6 edition 2.2 — SCL
- IEC 61850-8-1 consolidated edition — MMS/GOOSE mapping
- IEC TR 61850-7-6:2024 — Basic Application Profiles and SCL
- IEC 61850:2026 series catalogue — Current part/edition overview
Engineering note: A standardized logical node makes the communicated meaning visible; it does not replace the protection study, interlocking philosophy or end-to-end functional test.