Should automation and power distribution share a control network?

Should automation and power distribution share a control network?

Automation and power distribution can share network infrastructure, but they should not automatically share the same failure domain. That distinction matters more than whether both systems use Ethernet. A common supervisory backbone may be sensible; putting machine control, electrical protection, remote maintenance, and reporting traffic on one unrestricted network usually is not.

The decision depends on what the network must carry, what happens when communication disappears, and who can change its configuration. Integration can simplify load management, fault diagnosis, and energy reporting. Poorly bounded convergence can also turn a switch replacement or broadcast storm into a plant-wide operational problem.

The useful question is therefore not simply “Can these systems communicate?” It is “Which functions can safely share infrastructure, and which must remain independent?”

Start with the function, not the protocol

An energy dashboard reading a meter and a protection relay exchanging a trip-related message have very different requirements. Grouping both under “electrical communications” hides the distinction that should drive the architecture.

Separate the proposed traffic into operational functions before selecting switches or gateways:

• Monitoring: meter values, equipment status, event records, and historical trends. Short interruptions may be tolerable, provided stale data is clearly identified.
• Supervisory control: breaker commands, demand limits, operating-mode changes, and power setpoints. These require defined authorization, command handling, and loss-of-communication behavior.
• Time-sensitive coordination: machine interlocks, load shedding, and electrical protection messaging. Timing and availability requirements must come from the actual application.
• Engineering access: programming, firmware updates, configuration transfers, and diagnostics. This traffic may be intermittent, but its operational impact can be substantial.

A protocol name does not establish suitability. IEC 61850 includes services with different communication characteristics; ordinary supervisory polling should not be assessed as though it were protection messaging. Likewise, selecting industrial Ethernet equipment does not, by itself, prove that an end-to-end timing requirement will be met.

Where sharing makes engineering sense

Consider a manufacturing site that wants production schedules, feeder loading, and electricity demand visible in one operations interface. The automation system needs electrical information to sequence large loads, while the electrical team wants production context when investigating demand peaks. Sharing data is valuable here. Sharing every underlying control dependency is unnecessary.

A reasonable arrangement is to keep local machine control and electrical protection within their respective zones, then exchange approved information through a controlled supervisory connection. Meter readings, equipment availability, and selected operating requests can cross that boundary without exposing every relay or controller to every workstation.

For the Global Industry Synergy Network (GISN), whose industrial coverage spans machinery, renewable energy, and energy storage, this distinction is particularly relevant: integration should be judged by the operational dependency it creates, not by the number of systems appearing on one dashboard.

Sharing is easier to justify when local equipment remains stable during a supervisory outage, exchanged commands have clear limits, and network maintenance can occur without disabling essential functions. It is harder to justify when the integration becomes the only path for a critical protective action.

Choose the boundary before choosing the hardware

“Shared network” can describe several architectures. They do not offer equivalent fault containment.

VLANs separate broadcast domains; they are not a complete security architecture. Access between zones still needs enforcement through appropriately configured routing controls, firewalls, or other suitable mechanisms. A VLAN also cannot protect two applications from the failure of the switch carrying both.

Conversely, physical separation is not absolute independence. Two networks may still rely on the same cabinet power supply, fiber route, engineering laptop, or authentication service. A credible design review follows these dependencies rather than stopping at different cable colors.

The difficult performance test is the abnormal operating state

Average bandwidth utilization says little about whether a critical message will arrive on time during a disturbance. A quiet network may become busy precisely when electrical faults trigger events, alarms, waveform retrieval, and operator activity.

Define performance requirements end to end: device processing, transmission, switching, any security inspection, and receiving application behavior. Include acceptable delay variation, packet loss, and recovery time. Obtain the limits from the protection study, control design, and equipment documentation rather than applying one generic latency target across the site.

Quality of service can prioritize selected traffic during contention, but it cannot repair an overloaded receiver or a failed switch. Multicast filtering can limit unnecessary traffic, but its behavior depends on correct configuration and device support. Redundant paths only help when the recovery mechanism meets the application's interruption tolerance.

For protection communications, IEC 61850 requirements and, where applicable, IEC 62439-3 redundancy mechanisms such as PRP or HSR may inform the design. Their presence in a specification is not proof of performance. The actual topology, device implementation, and failure behavior still need validation.

Keep protection independence explicit

A useful review question is: if the shared backbone disappears, what still trips, what still runs, and what stops?

Some protection functions operate locally from measured electrical quantities. Others depend on communication between devices. Neither “all protection is independent” nor “all protection needs a separate network” is a sound blanket rule. Trace each protective function and establish whether communication loss causes loss of protection, fallback operation, blocking, or another defined response.

Load shedding deserves similar scrutiny. A slow demand-management request and an emergency load-shedding action may look similar on an operator screen, yet have very different consequences if delayed. Their communication paths should reflect those consequences.

Safety-related control functions require their own assessment under the applicable functional safety framework. Neither ordinary network separation nor an industrial firewall establishes the required safety integrity.

Cybersecurity and maintenance meet at the same boundary

The IEC 62443 series provides a useful zones-and-conduits framework for industrial cybersecurity. Applied here, the practical task is to identify assets with compatible security needs, then specify which communications may cross between them. Segmentation should follow risk and function, not merely department names.

Document who initiates each connection, its destination, its purpose, and whether it permits reading, writing, or engineering changes. “The systems need to communicate” is not a sufficient access rule. Remote maintenance should use a controlled entry path, with access restricted to the equipment and period required.

Operational ownership can be the deciding factor. Electrical assets may follow a different maintenance schedule from production controllers. If both depend on a shared switch, a firmware update requires coordinated approval, a rollback plan, and an agreed outage window. Without that governance, nominal infrastructure savings can become recurring maintenance conflicts.

Also examine the proposed interface itself. A gateway that translates data between networks may become a single point of failure. Define what downstream equipment does when values stop updating: retain a bounded setting, revert to local operation, reject commands, or enter another engineered state. Displaying the last good value without a stale-data indication is not an acceptable substitute.

What to require before approving convergence

Approval should rest on demonstrated behavior, not a clean topology drawing. Ask the integrator to provide a traffic matrix, dependency map, failure-response description, and maintenance responsibility matrix. Then test the assembled system under representative operating and disturbance conditions.

• Remove a shared uplink or switch and measure interruption and recovery against application limits.
• Run permitted engineering transfers alongside critical traffic and observe endpoint behavior, not just switch counters.
• Verify that unauthorized commands are blocked and legitimate commands reach only their intended destinations.
• Disconnect the supervisory interface and confirm local protection, control fallback, alarms, and stale-data handling.
• Restore saved configurations on replacement hardware and confirm that segmentation and access rules survive recovery.

Potentially disruptive tests belong in a controlled commissioning environment or an approved outage procedure, not an improvised live-plant experiment. Record acceptance criteria beforehand so that “nothing obvious happened” does not become the test result.

For many facilities, the defensible choice is selective convergence: share supervisory information, tightly control commands, and preserve independent operation where failure consequences demand it. Approve broader sharing only when timing, fault containment, security controls, and maintenance ownership have been demonstrated. If losing one common switch produces an unacceptable combined outage, the architecture needs a stronger boundary—not another dashboard.