An IEC 61850 change is safe only when SCL, IED settings, network/time configuration, drawings and tests describe the same released system. Updating one relay locally without reconciling the master SCD creates configuration drift; updating a dataset can affect many subscribers even when only one publisher file changed.
This guide defines version identity, ownership, semantic change review, approval, deployment, rollback, as-built reconciliation and audit for protection/control systems.
1. Treat the system as one configuration item
- Requirements, SLD, protection philosophy and cause-effect/GOOSE matrix.
- Vendor ICD/IID files and namespaces.
- Master SSD/SCD and generated target CIDs/device files.
- Relay protection/control settings and logic.
- Switch VLAN/QoS/multicast/PRP/HSR and clock/PTP configuration.
- HMI/gateway database, point list and graphics.
- Firmware, tool versions, licences and dependencies.
- FAT/SAT/regression scripts, captures and results.
2. Version identity
| Object | Identity fields | Verification |
|---|---|---|
| SCL | File name, Header id/version/revision/history, namespace, hash | Validator and semantic diff |
| IED | Model, serial, hardware, firmware, options, loaded file/hash | Device readback/record |
| Settings | Setting group/file revision/checksum | Compare/readback and functional test |
| Network/time | Device, firmware, config revision/hash | Export/readback and traffic/time test |
| Test evidence | Requirement/case/config/tool/calibration revision | Traceability matrix |
3. Ownership and engineering rights
- Owner/design authority owns protection/control requirements and approves safety impact.
- System configuration authority owns master SCD and system addresses/subscriptions.
- IED engineer owns device capability/settings within allocated rights.
- Network/time engineer owns switches, redundancy, multicast, QoS and clocks.
- Cyber authority owns access, credentials, secure configurations and release controls.
- Commissioning authority controls loaded site state and test restoration.
- No tool or person may overwrite another domain without an agreed exchange/reconciliation process.
4. Change request content
- Problem, requested outcome and initiating event.
- Affected bays/functions/devices/files and current baseline.
- Protection, safety, operations, network, cyber and regulatory impact.
- Exact proposed semantic/configuration difference.
- Outage and backup protection/control plan.
- FAT/SAT/regression cases and pass limits.
- Deployment sequence, responsible roles and communication.
- Rollback trigger, package and maximum recovery time.
5. Semantic impact analysis
- IED/LN/data model/process association changes.
- Dataset membership/order and ConfRev.
- GOOSE/SV/report control blocks and addresses.
- Subscriber ExtRefs and reverse dependencies.
- Protection settings, logic, timers and outputs.
- VLAN/priority/multicast, bandwidth and redundancy paths.
- PTP profile/domain/grandmaster and quality behavior.
- Cyber access, services, keys/certificates and logs.
- Drawings, HMI/gateway point mapping and operator procedures.
6. Risk classification and approval
| Class | Example | Minimum assurance |
|---|---|---|
| Editorial/no functional effect | Controlled description text | Validator/diff and document review |
| Local non-critical | Alarm threshold/display mapping | Bench/FAT plus affected SAT |
| Protection/control functional | Setting, ExtRef, interlock or control | Independent engineering review and end-to-end regression |
| System/common mode | Dataset template, switch/PTP/firmware/tool update | Multi-discipline approval, representative/full regression and rollback rehearsal |
7. Controlled engineering workflow
- Copy/branch the approved baseline; never edit the only master.
- Apply the authorized change with qualified tool versions.
- Run XML/schema/OCL and project semantic rules.
- Generate semantic diff and dependency/impact report.
- Independent-review critical functions and approve.
- Generate target files; validate they match the master.
- Test in representative lab/FAT with final settings/network/time.
- Create signed/hashed deployment and rollback packages.
- Deploy under outage/backup plan and perform SAT.
- Reconcile as-left state, approve as-built release and close change.
8. Deployment sequencing
- Identify publisher/subscriber compatibility during partial deployment.
- A dataset/ConfRev change can require coordinated subscriber updates.
- Maintain independent backup protection during unavailable/ambiguous states.
- Control simulation/test/output blocks and operator authority.
- Load network/time infrastructure before/after IEDs according to tested sequence.
- Pause at defined verification gates; do not continue on unexplained alarms.
- Keep rollback media/files and skilled staff at site.
9. Verification after deployment
- Read back device identity, firmware, settings and loaded configuration hash.
- Verify affected reports/controls/GOOSE/SV/time and physical outputs.
- Test each redundant path and alarms.
- Confirm HMI/gateway/event mapping and control authority.
- Clear test/simulation/subscription/output blocks.
- Record network/time baseline and check no unintended traffic.
- Obtain operations/protection/commissioning acceptance.
10. Emergency change
Emergency action can shorten approval lead time but must not eliminate identity, backup, test and reconciliation. Define who may authorize, minimum pre-change backup, immediate functional check and mandatory retrospective review.
- Record reason, time, personnel and exact before/after state.
- Preserve the original package and rollback.
- Use temporary setting/change with expiry where appropriate.
- Maintain protection coverage and notify operations.
- Recreate/test/reconcile in the master system promptly.
- Audit that the temporary change did not become an undocumented permanent baseline.
11. Audit and drift detection
- Periodically export/read device, switch and clock configurations.
- Compare semantic state and hashes with approved baseline.
- Investigate every unexplained firmware/settings/subscription/address difference.
- Review access and configuration logs.
- Check field drawings, labels and asset identities.
- Trend recurring emergency/temporary deviations.
- Test backup restore and repository disaster recovery.
12. Change-impact examples
| Proposed change | Hidden dependencies | Regression scope |
|---|---|---|
| Add member to GOOSE dataset | ConfRev, all subscribers, frame size, test tools | Every subscriber plus timeout/performance |
| Relay firmware update | Data model, timing, SCL, settings conversion, cyber | IED round-trip and all critical functions |
| Switch VLAN/QoS update | GOOSE/SV/PTP paths and queues across bays | Connectivity, load, timing and redundancy |
| PTP grandmaster/profile change | All MUs/relays, holdover and event chronology | Offset, failover and protection security |
| Protection setting change | Trip matrix, BF/backup coordination and HMI | Study boundaries and physical trip chain |
| IED replacement | Firmware/options, address, CID, calibration, outputs | Complete bay primary-to-breaker SAT |
13. Rollback package
- Last approved SCD/CIDs/settings and switch/time/gateway configurations.
- Compatible firmware/installers, tool versions/licences and vendor instructions.
- Device identity/serial/port/credential provisioning under controlled access.
- Step-by-step rollback sequence respecting publisher/subscriber compatibility.
- Backup protection and outage plan during restoration.
- Verification cases and success/failure decision gates.
- Known irreversible conversions or database schema changes.
- Responsible roles, support contacts and estimated restoration time.
14. Release-completion checklist
- Approved change request and semantic impact report.
- Validator/diff/independent review complete.
- FAT/SAT evidence closes every affected dependency.
- As-left hashes/readbacks match released files.
- No test/simulation/output blocks or temporary access remain.
- Operations procedures, alarms, drawings and asset register updated.
- Rollback package and clean backups verified.
- Master SCD/repository is the final as-built source of truth.
References and further reading
- IEC 61850-4 consolidated edition — System and project management
- IEC 61850-6 edition 2.2 — SCL
- IEC TS 61850-6-3:2025 — SCL validation rules
- IEC TR 61850-90-30:2025 — Function modeling/engineering collaboration
- IEC TR 61850-10-3:2022 — Functional testing
- IEC 62351-6:2020 — IEC 61850 security
Engineering note: A released version is a tested system state, not a filename. It must bind SCL, settings, networks, time, firmware, evidence and the installed asset.