Substation automation: how field devices, IEDs, SCADA, and operations work as a single system

A value on the screen looks simple: “breaker open”, “current of 412 A”, “protection operated”. But before it reaches the operator, this information travels through a physical and logical chain.

Consider the position of a circuit breaker. Auxiliary contacts represent its state. The information is acquired by an input, interpreted by an IED or controller, and associated with a model. The device assigns state, quality, and time. The network transports the update. The server or gateway processes and distributes the point. The HMI presents the result. If there is remote integration, the operation center also receives it.

The visible value is only the last step. To trust it, engineering needs to answer:

A command travels in the opposite direction, but requires additional safeguards. An opening or closing command may involve:

Not every project uses the same command model. What matters is that the sequence is specified, applied consistently, and tested end to end.

A piece of operational information should be treated as something larger than an isolated value:

This is where automation meets the electrical system. It includes circuit breakers, disconnectors, transformers, sensors, CTs and VTs, contacts, actuators, and, when adopted, process interface units or merging units. In conventional architectures, currents, voltages, and states reach the panels through copper cables. In process-bus architectures, part of these quantities and states can be digitized closer to the primary equipment and transported over the network.

The process level is not “just the field”. It is the point where an error of polarity, ratio, wiring, mapping, time, or operation can turn into incorrect information or improper operation.

It brings together devices associated with a functional position of the substation: protection relays, bay controllers, meters, recorders, and local logic. At this level there can be acquisition and validation of states, metering, protection, interlocking, local sequences, command execution, publishing and subscribing of messages, and concentration of the equipment’s own diagnostics.

Distributing functions by bay can reduce dependence on a central server, but it requires consistency between devices, files, and versions.

It is the local coordination layer. It can include automation and SCADA servers, operation and engineering workstations, telecontrol gateways, switches and network infrastructure, synchronism services, historical data, alarms, and event logging, in addition to controllers for functions common to the substation. It is at this level that much of the data gains a consolidated operational representation — and where inconsistencies in naming, alarm priority, screens, permissions, and communication become most visible.

It includes local or remote control centers, authorized corporate systems, analysis applications, and controlled remote-access channels. Communication can use protocols and gateways defined by the utility or the project. The operation level must not be confused with unrestricted access to the station network. Integration requires clearly defined limits, responsibilities, monitoring, and security criteria.

A single piece of equipment can accumulate roles. This does not remove the need to describe them. When different functions reside in the same device, a common failure can affect all of them; when they are distributed, dependencies on network, time, and coordination arise.

Selecting equipment without consolidating functions usually produces gaps or overlap. Before choosing models, it is best to map:

The most dangerous command is the one that reaches the correct equipment without the system having verified the correct context. A control architecture must make clear:

“Local/remote” cannot be just a label on the HMI. The position of selector switches, equipment states, user permissions, and internal logic must result in an unambiguous authority model.

If two sources can act simultaneously without a defined rule, automation creates conflict instead of coordination. If the transfer of authority is not recorded, the investigation of an event loses context.

An interlock prevents or conditions an operation based on the state of the process. Its implementation can be electrical, logical, mechanical, or a combination. The choice depends on criticality, requirements, and the project’s philosophy. For each command, document:

Testing only the “happy path” proves little. It is necessary to verify the block when a condition is not met, when a data point is invalid, and when a dependency disappears.

Issuing an output does not mean the equipment changed position. Automation must distinguish, where applicable: command accepted; command sent; output activated; movement started; final position reached; time exceeded; inconsistent position; circuit failure or unavailability. This distinction reduces ambiguity for operation and improves field diagnostics.

SCADA turns distributed data into an operational view. Its quality depends as much on screen design as on the engineering behind it. Functions can include acquisition, processing, alarms, events, historical data, commands, calculations, reports, data exchange, and supervision of the infrastructure itself. In installations subject to ONS requirements, the applicable scope must be verified directly in the Grid Procedures and in the project documents.

A value needs to indicate when it should not be interpreted as normal. Depending on the system and protocol, the quality can reflect situations such as:

Hiding quality or indiscriminately converting it to “zero” creates false certainty. On the HMI, invalid states must be perceptible without visually competing with real alarms.

An event is a recorded change. An alarm is a condition that requires attention or a response from the operator. Not every event should become an alarm. A good alarm design seeks to avoid:

The sequence-of-events record, often called SOE, helps to reconstruct the order of an event. Its usefulness depends on the timestamp at the source, synchronism, time resolution, and preservation during communication outages.

The screen must help the operator perceive the state and act safely. This means:

There is no “best protocol” apart from the use case. The design must define which information needs to flow, between which participants, and with what performance, semantics, availability, and security.

In IEC 61850, different services meet different needs. MMS is associated with client-server communication and structured access to data and services. GOOSE uses publish/subscribe to distribute events and states with performance suited to fast functions, as defined by engineering. Sampled Values publishes samples of electrical quantities and is tied to the use of a process bus.

An installation can use MMS and GOOSE without adopting Sampled Values. It can also integrate legacy equipment through other protocols. Saying that a substation “has IEC 61850” does not yet describe its architecture.

A gateway can transform representations, but engineering needs to decide:

When this equivalence table is not controlled, the integration becomes dependent on the tacit knowledge of whoever configured it.

Treating IEC 61850 as merely “another Ethernet protocol” hides an important part of its value. The series establishes a common structure to represent functions and data of the electrical domain, communication services, and a system configuration language.

In traditional integrations, much of the meaning resides in external lists of registers or points. In IEC 61850, data is organized into standardized models, with classes and attributes that help tools and systems understand what is being represented. This does not remove the engineering. It increases the possibility of consistency — provided that naming, model extensions, datasets, controls, and files are treated as system deliverables.

The SCL language, defined in IEC 61850-6, allows describing IED capabilities, functions, topology, and communication configuration for exchange between tools. Files found in the engineering cycle include, depending on the edition, tool, and adopted process:

The SCD file deserves special attention because it coordinates relationships between multiple participants. It should not exist only as an occasional export. It is necessary to define its official source, owner, version, validation, and update process.

Standard conformance and declared service support are important foundations, but they do not replace application validation. Differences in edition, model, interpretation, options, tools, and behavior can affect the integration. A multi-brand FAT must verify, among other things:

The station bus connects devices and systems at the bay and station levels. The process bus brings digitalization and communication closer to the primary equipment, and can transport states, commands, and sampled values.

A process bus can reduce wiring and expand supervision possibilities, but it also changes the nature of the dependencies. Network, synchronism, configuration, testing, and maintenance become even more decisive. The decision must consider the full life cycle, the available competence, and the expected behavior under faults — not just the reduction of cables.

In a star topology, devices connect to central or access switches. The architecture is clear and can be easily segmented, but availability depends on how switches, uplinks, power sources, and paths are distributed. In rings with recovery protocols, there is an alternative path after certain failures. The recovery time and the effect on the functions depend on the protocol, the configuration, the size of the network, and the equipment. Do not assume instantaneous recovery without measurement.

PRP and HSR, defined in IEC 62439-3, are high-availability redundancy mechanisms. Under conditions and failures foreseen by the design, they can offer switchover with no recovery time perceived by the protected traffic.

This does not make the entire installation immune to failures. If the two networks share a power source, physical route, incorrect configuration, or another common point, the benefit can be reduced. Servers, gateways, clocks, switches, IEDs, and final circuits must be analyzed within the architecture.

Logical segmentation and prioritization help to control domains and traffic. In IEC 61850 environments, multicast messages require conscious configuration and supervision. VLAN and priority do not compensate for a network without a traffic budget, documentation, or diagnostics. The network design must record at least:

Misaligned clocks can make a correct sequence appear contradictory. In distributed systems, time influences events, oscillography, sampled values, correlation between devices, and event investigation. The design must define:

Common technologies include NTP, IRIG-B, and PTP. NTP serves many general functions, but it should not be assumed to be a solution for high-accuracy requirements. IRIG-B remains present in conventional architectures. PTP, including the IEC/IEEE 61850-9-3 profile, serves precise synchronism applications in automation networks, when the entire chain is compatible and correctly designed. GPS or another GNSS source can provide the primary reference, but the antenna alone does not solve distribution, redundancy, supervision, and holdover behavior.

Deliberately disconnecting the time source during commissioning helps to verify which alarms appear, which devices remain synchronized and for how long, how the time quality changes, how recovery occurs, and whether jumps or incoherent sequences appear.

The terms describe architecture choices and degree of integration. They do not represent an automatic scale of reliability.

A well-designed and well-maintained conventional architecture can be more reliable than a poorly specified digital architecture. Likewise, a mature digital solution can increase observability, flexibility, and standardization. The benefit comes from fitness to the requirement and from the execution of the engineering.

Retrofit projects may be implemented in stages:

A hybrid architecture is not necessarily improvised. It can be a planned stage — provided that interfaces, limitations, and final condition are documented.

Automation increases connectivity and dependence on software. This requires defense in depth and governance throughout the life cycle. Controls to consider, according to risk and project requirements:

The IEC 62351 series addresses security of communications and data in power-sector protocols, including parts related to IEC 61850. It is an important reference, but it does not replace network architecture, processes, people, and operational controls.

Indiscriminately updating a critical system can introduce unavailability. Leaving software vulnerable indefinitely is also a risk. Engineering needs to combine impact assessment, homologation, window, rollback, and test evidence. Likewise, an “emergency” remote access without traceability can become permanent. Every exception needs an owner, a deadline, and a closing condition.

In operating installations, the challenge is rarely to design only the future architecture. It is to understand what exists, define transition states, and carry out the change without creating hidden risks.

Old documents are a starting point, not proof of the current state. The survey must confront drawings and field:

Migrating an old point list without validating names, quality, alarms, and usefulness only transfers liabilities to the new platform. The retrofit is an opportunity to rationalize:

Between the current system and the future one there is a period in which new and old parts need to coexist. Engineering must explicitly represent:

There is no universal strategy. Required availability, access to the process, existing documentation, testing capacity, and the risk of each transition guide the choice.

These signs do not by themselves determine replacement. They indicate the need for a structured technical diagnosis.

A robust process includes:

Complex projects fail silently when divergent copies of the same file exist. Define:

FAT should be performed in an environment sufficiently representative to anticipate problems before field deployment. Depending on the scope, verify:

The FAT does not fully reproduce the field. Simulation limitations must be recorded and converted into mandatory SAT or commissioning cases.

On site, validate the actual installation:

The end-to-end test follows a complete function. Examples:

“Communication OK” is not a sufficient criterion. Each case must contain:

After entering operation, automation keeps changing. There are replacements, updates, new points, screen revisions, bay expansions, equipment changes, and changes at the control center. Without life-cycle management, the as-built loses validity and the next diagnosis starts over from scratch.

Use the questions below as an initial guide. They do not replace the analysis of the project.

An automated substation is a distributed system applied to a critical electrical process. Its performance does not depend only on the speed of the network, the brand of the IED, or the appearance of the HMI. It depends on the coherence between what the field reports, what the devices interpret, what the network transports, what SCADA presents, what the operator can command, and what remains available when something fails.

This coherence is built through engineering: clear requirements, defined responsibilities, data with semantics and quality, reliable time, network architecture, controlled configurations, end-to-end tests, and documentation that remains valid after energization.

When these disciplines come together, automation ceases to be a set of connected equipment and begins to fulfill its role: expanding observability, reducing ambiguity, supporting decisions, and operating the system with predictability.

Standards, procedures, and contractual requirements evolve. The applicable version must be confirmed for the date, the utility, and the project.