IEC 61850 MMS is not simply “Ethernet polling.” It maps the IEC 61850 client/server model to a station LAN so an HMI, gateway or engineering client can read structured data, receive buffered or unbuffered reports, control primary equipment, retrieve files and supervise the IED. Reliable MV monitoring depends on the data set, report control block, trigger, optional fields, reservation, buffer and client behavior being engineered together.
This article explains the end-to-end design from IED information model to HMI/control center, with report configuration, quality/time handling, control, capacity, redundancy, cybersecurity and practical FAT/SAT.
1. Where MMS fits
- MMS client/server: station HMI, gateway, historian or engineering client accesses IED servers.
- Reporting: IED sends selected data changes/events to clients through report control blocks.
- Controls: client invokes the configured IEC 61850 control model for XCBR, XSWI or other controllable objects.
- Files: disturbance records or other files may be retrieved when supported.
- GOOSE: separate publisher/subscriber service for fast peer-to-peer events; it should not be confused with MMS reporting.
- Sampled values: separate process-bus measurement service, not SCADA telemetry.
2. Build from the information model
Start with primary equipment and operational functions, then map them to logical devices, logical nodes, data objects and data attributes. A breaker may use XCBR.Pos for position, XCBR.OpCnt for operations and condition-related objects from appropriate logical nodes; protection indications originate from protection logical nodes, not arbitrary generic tags. The exact model and presence are product/project dependent.
| SCADA need | IEC 61850 consideration |
|---|---|
| Breaker/switch position | Double-point/intermediate state, quality and source time |
| Protection start/operate | Function-specific LN/DO, transient capture and event time |
| Measurements | Magnitude, units, quality, deadband/change behavior |
| Equipment health | IED/device/communication/self-supervision distinctions |
| Control | Control model, origin, interlock/synchrocheck and termination |
| Mode/test/block | Visible operational states; never hidden as a normal value |
3. Data sets are the report payload contract
- Use stable, purpose-based data sets: critical events, equipment status, measurements, diagnostics or client-specific groups.
- Keep data-set order and members under SCD/version control; a client may associate received entries by configuration.
- Do not place every available attribute into one oversized report.
- Separate high-frequency analogs from infrequent alarms so analog activity cannot obscure critical events.
- Include value, quality and timestamp semantics required by the client; avoid reporting internal attributes with no operational owner.
- Verify whether the IED supports fixed or dynamic data sets and whether dynamic definitions persist after restart.
4. Buffered versus unbuffered reporting
| Feature | Buffered RCB (BRCB) | Unbuffered RCB (URCB) |
|---|---|---|
| Client disconnect | Eligible events retained up to IED buffer capacity | Events normally lost while report disabled/disconnected |
| Reconnect | Client can continue using entry/buffer tracking when engineered | Fresh enable/integrity required |
| Use | Operational events/SOE where outage recovery matters | Live display or non-critical data where recovery is unnecessary |
| Engineering burden | Reservation, ownership, buffer sizing/overflow and sequence recovery | Enable/reservation, integrity and gap handling |
Buffered reporting improves continuity but is not unlimited storage. Specify the longest credible client/network outage, worst event rate, available IED buffer and overflow indication. Retrieve disturbance files separately; do not expect a BRCB to be a historian.
5. Report trigger options
- Data change (dchg): report when a qualifying value changes.
- Quality change (qchg): essential for invalid, test, substituted or other quality transitions even if the displayed value is unchanged.
- Data update (dupd): report an update where the model defines update triggering without a value change.
- Integrity: periodic complete data-set report to re-establish confidence and detect missed state.
- General interrogation: client-requested full reporting, useful after initialization but not a substitute for correct event handling.
Trigger options are data-attribute/model dependent. The engineer should prove actual trigger behavior with the specific IED and configuration rather than assume every data item supports every trigger.
6. Buffer time, integrity period and event storms
- Buffer time: groups changes occurring within the configured interval into reports; too small increases traffic, too large adds latency.
- Integrity period: should restore confidence without flooding all IEDs simultaneously. Stagger timers across bays.
- Use measurement deadbands at the correct model/source, not only at the HMI, while never suppressing discrete status or quality transitions.
- Model a bus trip, DC disturbance or communication recovery that changes hundreds of points together.
- Verify maximum report size, segmentation behavior, client processing rate, TCP buffering and gateway northbound capacity.
- Alarm report-buffer overflow and treat the event history as incomplete until reconciled.
7. Optional fields and why they matter
- Sequence number helps the client identify report continuity but requires defined rollover/reconnect handling.
- Timestamp records report generation context; individual data timestamps remain important for source event time.
- Reason-for-inclusion tells why each member was sent and aids event interpretation.
- Data-set reference and data reference improve robust association/troubleshooting at some bandwidth cost.
- Configuration revision helps detect whether client and server data-set expectations differ.
- Entry ID and buffer-overflow information support buffered-report recovery and evidence of loss.
8. RCB instances, ownership and redundant clients
One report-control instance cannot be casually shared by multiple active clients. Specify how many HMI, gateway, historian and test clients may connect concurrently; reserve or assign RCB instances accordingly. A redundant HMI pair may use one active client with controlled takeover or separate instances. The standby must not steal ownership, reset buffered state or cause an event gap.
- Count usable RCB instances per data set and logical node, including maintenance/test clients.
- Document reservation persistence, owner identity and timeout behavior.
- Define enablement order after IED/client restart.
- Verify failover while reports are active and while the buffer contains unacknowledged events.
- Prevent duplicate alarm presentation when redundant clients temporarily overlap.
- Expose an alarm if no operational client owns/enables a required report.
9. Quality, timestamp and stale data
- Display invalid/questionable, test, operator-blocked, substituted and old-data conditions according to project policy.
- Preserve the source timestamp and time-quality information through gateway conversion.
- Define “stale” separately: an unchanged valid breaker position does not naturally generate new reports, so freshness cannot be inferred from last value change alone.
- Supervise the association, periodic integrity/heartbeat, IED health and report activity as separate indicators.
- On communication loss, do not freeze the last value as healthy; mark it stale/invalid while retaining it for context.
- After restoration, distinguish backfilled historical events from current process state.
10. Controls over MMS
- Choose the IEC 61850 control model: direct or select-before-operate, with normal or enhanced security, according to consequence and workflow.
- Map operator origin/category, ctlNum and command parameters consistently.
- Specify control timeout, select timeout, cancellation, duplicate command and client disconnect behavior.
- Interlock/synchrocheck, local/remote authority and process validity remain independent safety gates.
- Use command termination/LastApplError and independent position feedback to distinguish accepted, failed and completed actions.
- Never infer breaker operation solely from a successful MMS service response.
11. SCL and configuration ownership
- The SCD should be the controlled system record for IED addresses, models, data sets, RCBs and client associations.
- Validate the IED’s as-loaded configuration against the released SCD/IED-specific file.
- Track configuration revision and client database build together.
- Do not manually patch HMI tags after FAT without reconciling the SCD and point-list source.
- Record IED firmware, IEC 61850 edition, tool version and product namespace/model files.
- Regression-test reports and controls after any data-set, model, firmware or tool change.
12. Network and cybersecurity design
- Separate station operational MMS clients from engineering/maintenance access and process-bus traffic by zones/VLANs as the architecture requires.
- Permit only approved client/server flows; a reachable TCP port is not authorization.
- Apply IEC 62351-4 security mechanisms where supported and qualified, with certificates/keys and role lifecycle engineered.
- Protect SCD, HMI/gateway databases, IED configuration and backups from unauthorized modification.
- Monitor unexpected associations, repeated failed controls, report disable/configuration changes and certificate/time problems.
- Test secure-session performance and failover; do not add security without proving availability under event storms.
13. Capacity calculation
For each IED, estimate steady analog-change reports, discrete events, integrity reports, maximum credible burst and reconnect replay. Sum across bays and include concurrent HMI/gateway clients. Check IED report-buffer capacity, RCB count, MMS association count, station-switch bandwidth/queues, gateway processing and control-center ingest. The acceptance value is the worst observed latency and loss under the worst credible concurrent case—not an average ping time.
14. FAT/SAT test plan
- Freeze SCD, IED files, firmware, client database and report matrix.
- Browse/compare the actual server model against the released model.
- Verify each data-set member, trigger, reason-for-inclusion, quality and timestamp.
- Test BRCB/URCB enable, reservation, client disconnect, IED restart and client restart.
- Generate events during outage; validate entry continuity, replay order and overflow indication.
- Exercise integrity/GI, sequence/configuration revision changes and time loss/restoration.
- Test simultaneous analog activity and major discrete event storm at all bays.
- Execute every control success/rejection/timeout/cancel path with independent feedback.
- Fail active HMI/gateway/client and verify takeover without gaps or duplicate controls.
- Attempt unauthorized association/control/configuration and confirm logs/alarms.
- At SAT, repeat with actual IEDs, LAN, HMI/gateway and breaker auxiliary contacts.
- Archive packet captures, as-built files, hashes, results and residual limitations.
15. Common defects
| Defect | Consequence | Correction |
|---|---|---|
| One giant data set | Large reports and event congestion | Partition by function/rate/criticality |
| Only data-change trigger | Quality deterioration not reported | Include/test qchg where applicable |
| Insufficient RCB instances | Client cannot enable reports | Capacity/ownership matrix |
| No buffer-overflow test | False confidence in complete SOE | Forced outage/event-storm test |
| Manual client tags | SCD/HMI drift | Controlled import and comparison |
| Successful response treated as operation | False breaker-state conclusion | Termination plus independent feedback |
References and further reading
- IEC 61850-8-1 consolidated edition — MMS mapping, reporting and controls
- IEC 61850-7-2 consolidated edition — Abstract communication service interface
- IEC 61850-7-3 consolidated edition — Common data classes
- IEC 61850-7-4 consolidated edition — Logical nodes and data objects
- IEC 61850-6 edition 2.2 — SCL engineering
- IEC 61850-10 edition 2.1 — Conformance testing
- IEC 62351-4 consolidated edition — Security for MMS and derivatives
Engineering note: A report is trustworthy only when the client can prove which configured data changed, why it was included, what its source quality/time were and whether anything was lost during disconnection.