Station bus and process bus are functional layers, not simply the “upper” and “lower” Ethernet switches in a substation. Station bus connects bay IEDs with station-level supervision, control and engineering and also carries inter-IED messages. Process bus connects protection/control applications with digitized primary measurements, switchgear status and fast commands. They may use separate networks or a converged infrastructure, but their performance and failure boundaries must remain explicit.
This guide compares services, endpoints, latency, time, redundancy, traffic, cybersecurity, testing and failure modes; then provides a decision method for separate, hybrid and converged MV architectures.
1. Functional boundary
| Layer | Typical endpoints | Typical services/information |
|---|---|---|
| Station bus | Bay IEDs, HMI, gateway, SCADA interface, historian, engineering workstation, station controller | MMS reports/controls/files, inter-bay GOOSE, supervision, settings/engineering |
| Process bus | Merging units, process I/O, breaker interfaces, sensors, protection/control IEDs | Sampled Values, fast GOOSE trips/status/interlocks, time synchronization |
| Cross-layer services | Clocks, management, security/logging, engineering tools | PTP/SNTP, monitoring, configuration, diagnostics |
An inter-bay protection GOOSE between two relays can be functionally station-bus traffic even though it is time-critical. A breaker trip GOOSE to a process I/O device is process-bus traffic. The physical port or switch rack alone does not define the layer.
2. Station-bus applications
- Buffered/unbuffered reporting of status, alarms, measurements and events to station clients.
- Operator controls and select-before-operate/direct control according to the model.
- Inter-bay GOOSE for transfer trips, breaker failure, blocking, load shedding and interlocking.
- Gateway mapping to control center protocols.
- IED supervision, setting/configuration access and file retrieval.
- Station time distribution or access to time infrastructure.
- Network/device management, security logging and asset monitoring.
Station bus is not “non-critical.” A transfer-trip GOOSE may have protection-class performance, while an HMI indication can tolerate far more delay. Requirements follow the function, not the bus label.
3. Process-bus applications
- SV streams for protection, control, metering and monitoring.
- Breaker/disconnector/earthing-switch position and process alarms.
- Trips, closes, interlocks and process interface outputs via GOOSE.
- Sample alignment and time-quality information.
- Test/simulation streams and process-device diagnostics.
- Digital interfaces to conventional CT/VT, LPIT and integrated switchgear sensors.
Process-bus traffic is continuous and deterministic in character: SV consumes predictable high packet rates, while protection GOOSE produces event bursts and retransmission. Loss, jitter or time error can directly affect protection availability or security.
4. Separate, hybrid and converged topologies
| Option | Benefits | Main risks/costs |
|---|---|---|
| Physically separate buses | Clear fault/security domains; easier capacity reasoning | More switches, fibers, spares, management and gateways |
| Hybrid with controlled interconnection | Critical process traffic separated; selected shared services | Boundary device/link becomes important dependency |
| Converged infrastructure | Fewer devices/ports; flexible routing and shared management | Common-mode overload/config/cyber failure; more complex assurance |
| Bay-local process network + station backbone | Contains SV per bay and scales modularly | Inter-bay process functions and maintenance need explicit paths |
Convergence is acceptable only when traffic engineering, VLAN/QoS, multicast control, redundancy, security zones and failure containment prove every critical function. Logical VLAN separation on one switch is not equivalent to independent hardware.
5. Traffic characteristics
| Traffic | Pattern | Key design issue |
|---|---|---|
| SV | High-rate, continuous multicast | Bandwidth, jitter, loss, queue and subscriber capacity |
| Protection GOOSE | Low stable rate, rapid burst after change | End-to-end transfer time and dependability under burst/load |
| MMS reports/control | Client/server, event and request driven | Session/client limits, buffer, reconnect and security |
| File/engineering traffic | Occasional high-volume | Rate-limit/segregate so it cannot affect protection |
| PTP | Periodic event/general messages | Priority, asymmetry, transparent/boundary clock behavior |
| Management/security | Polling, telemetry, logs, updates | Controlled access and protection from storms/scans |
Calculate utilization per egress queue and link using actual frame sizes/rates, duplicated PRP/forwarded HSR traffic, simultaneous GOOSE bursts, reports after disturbance and credible engineering transfers. Average backbone percentage can hide a congested bay port.
6. Performance allocation
- Assign requirements by function using IEC 61850-5, not one latency value for an entire LAN.
- Measure GOOSE application-to-application transfer time, not ping or switch forwarding alone.
- Include SV acquisition, MU processing, network, subscriber and protection algorithm in the operating-time budget.
- Define packet loss, jitter and out-of-order tolerance for each subscriber.
- Reserve margin for abnormal but credible event bursts and a failed redundant path.
- Specify time error separately from network latency.
- Prove the final physical action: breaker trip, control rejection or HMI indication as applicable.
7. Time is a cross-layer service
Process-bus SV may require precise phase alignment between MUs; station event logs require consistent chronology; synchrocheck or synchrophasor applications impose their own accuracy. A shared PTP infrastructure can serve both layers but becomes a common dependency.
- Document grandmasters, GNSS, domains/profiles, clock roles, paths and holdover.
- Separate accuracy requirements for sample alignment, protection algorithms and event records.
- Analyze common time error versus differential error between publishers.
- Do not assume PRP/HSR automatically makes PTP redundant; verify device and profile behavior.
- Test loss, drift, grandmaster changeover, path asymmetry and recovery while protection is active.
- Define quality/alarm/fallback response for every subscriber.
8. Redundancy and fault containment
PRP/HSR can remove conventional network recovery time for one fault, while RSTP or routed redundancy restores paths after a finite interval. None prevents a common configuration, power, fiber-route, storm, firmware or cyber failure. Build a dependency map for each critical function.
- Physically separate LAN A/B power, switches, ports, fibers and routes.
- Monitor both paths so seamless delivery does not hide a latent failure.
- Limit the fault domain: one malformed/flooded process VLAN should not overwhelm all station services.
- Verify redundancy boxes and single-attached nodes do not form bottlenecks.
- Test return to normal redundancy, not only failure transition.
- Define behavior for simultaneous and common-mode failures that exceed the N-1 claim.
- Coordinate network redundancy with duplicated sensors, MUs, relays, outputs and trip coils.
9. Failure modes by layer
| Failure | Station-bus effect | Process-bus effect |
|---|---|---|
| Switch/port/link | Loss of HMI/report or inter-bay GOOSE | Loss/jitter of SV, trip/status GOOSE |
| Multicast filtering error | GOOSE suppressed or flooded | SV/GOOSE suppressed or flooding overload |
| Time failure | Bad event chronology; some applications affected | Misaligned samples; differential/security risk |
| Network storm/scan | Slow clients, reports or controls | Queue loss can affect protection directly |
| SCL/configuration error | Wrong reports, controls or subscriptions | Wrong bay/channel/trip path despite healthy packets |
| Gateway/HMI loss | Operator/remote visibility and control loss | Local protection can remain independent if designed |
| MU/process I/O loss | Diagnostic alarms on station bus | Measurement/output function lost |
A converged network couples these effects: a station-level engineering transfer or compromised host can consume resources used by process protection unless policies and hardware enforce containment.
10. Cybersecurity zoning
- Define security zones/conduits based on function, access and consequence—not just VLAN numbering.
- Keep routine enterprise/remote traffic away from real-time process domains through controlled interfaces.
- Use least privilege for IED, switch, clock and engineering tools.
- Disable unused services/ports and authenticate/record configuration changes.
- Control multicast publishers and detect duplicate/unauthorized APPID/MAC/IP identities.
- Apply IEC 62351 measures according to protocol/device support and verify performance impact.
- Coordinate patching with outage, backup, rollback and end-to-end regression testing.
- Protect SCL and network configurations because they reveal topology and protection dependencies.
11. Engineering and SCL boundaries
The SCD should model the complete system even if station and process networks are physically separated. It links primary topology, IED capability, datasets, GOOSE/SV control blocks, addressing and subscriptions. Network diagrams and switch configurations remain required; SCL alone does not necessarily encode every security/QoS/physical-route detail.
- Assign ownership of substation model, IED model, address plan, time, network and datasets.
- Keep unique registers for IP, MAC, APPID, VLAN and PTP domains.
- Validate station MMS/report clients and process SV/GOOSE subscriptions separately.
- Perform semantic change review across the layer boundary.
- Release SCD, CIDs, IED settings, switch/clock/security configurations and drawings together.
- Reconcile site changes back into the master system.
12. Test strategy differs by function
| Test | Station bus | Process bus |
|---|---|---|
| Protocol/conformance | MMS/report/control/GOOSE behavior | SV/GOOSE/time behavior |
| Functional | HMI, gateway, interlocks, transfer schemes | Measurement, protection, trip and breaker operation |
| Performance | Critical GOOSE/control/report recovery | SV loss/jitter/time and GOOSE trip transfer |
| Failure | Client/gateway/network redundancy | MU/I/O/time/network/trip path |
| Cyber | Access, sessions, segmentation, logs | Unauthorized streams, storms, test-mode containment |
IEC 61850-10 conformance testing is necessary but does not prove the project application. IEC TR 61850-10-3 and IEC TS 60255-216-1 support system/protection functional and interoperability testing. FAT must use the final SCL and realistic topology/load; SAT must prove installed fibers, primary signals and breaker circuits.
13. FAT checklist
- Approve the functional boundary, network topology and dependency diagrams.
- Validate SCD and all station/process subscriptions.
- Prove station reporting, control, HMI/gateway and inter-bay GOOSE.
- Inject every SV channel and test protection plus process GOOSE outputs.
- Measure function-specific latency under normal and worst credible traffic.
- Fail every link, switch, redundancy node, time source and shared service.
- Apply MMS/file/engineering load while monitoring real-time queues.
- Inject wrong/duplicate multicast, bad quality, stale data and test/simulation states.
- Verify alarms identify layer, device, path and consequence.
- Freeze and hash the complete system release after closing defects.
14. Decision framework
- Consequences: Which single/common failures can trip or disable multiple bays?
- Scale: How many SV streams, subscribers, bays and future additions?
- Performance: Can every queue/path meet protection timing with margin?
- Independence: Is physical separation required for duplicated protection?
- Maintenance: Can staff isolate, diagnose, replace and restore without unsafe ambiguity?
- Cybersecurity: Can access and traffic be contained while retaining supportability?
- Tool governance: Is there one controlled SCD and multi-vendor workflow?
- Lifecycle cost: Count switches, fibers, licenses, training, spares and periodic proof—not copper alone.
Choose the simplest topology that demonstrably meets these requirements. Separation can reduce common-mode risk; convergence can reduce hardware and enable flexibility. Neither is intrinsically safer without evidence.
15. Acceptance criteria
- Functional and physical station/process boundaries are documented.
- Every critical service has a performance and failure requirement.
- Traffic calculation covers bursts, disturbance reports, redundancy and maintenance.
- Time, power and configuration common modes are identified.
- Security zones and access routes cannot silently impair real-time traffic.
- FAT/SAT proves normal, N-1, overload and recovery states.
- Monitoring exposes loss of redundancy before a second failure.
- As-built SCD/network/time/security/device files are controlled and recoverable.
References and further reading
- IEC 61850-8-1 consolidated edition — MMS and GOOSE mapping
- IEC 61850-9-2 consolidated edition — Sampled values
- IEC 61850-5 consolidated edition — Communication requirements
- IEC 61850-3:2013 — General requirements
- IEC 62439-3:2021 — PRP and HSR
- IEC TR 61850-10-3:2022 — Functional testing
- IEC TS 60255-216-1:2025 — Protection interoperability tests
- IEC 62351-6:2020 — IEC 61850 security
Engineering note: Never classify a packet path as non-critical merely because it is called “station bus,” and never assume a VLAN makes a process bus independent. Follow the protection/control function end to end and test the dependencies that can actually prevent or initiate operation.