electrical-engineering-portal.

com
http://electrical-engineering-portal.com/hardware-implementation-of-substation-control-and-automation

Hardware Implementation of Substation Control and Automation

Google+

Hardware Implementation of Substation Control and Automation (on photo: Grid automation technology - FIONA - Flexible intelligent local network automation;
credit: ABB)

Substation control system //

To form a substation control system, the various elements described above must be assembled into some form of
topology. Three major hardware topologies can be identified as being commonly used, as follows:
1. HMI based Topology
2. RTU based Topology
3. Decentralised Topology

HMI based Topology

This takes the form of Figure 1. The software to implement the substation control and automation functions
resides in the HMI computer and this has direct links to IEDs using one or more communications protocols.
The link to a remote SCADA system is normally also provided in the HMI computer, though a separate interface unit

may be provided to offload some of the processor requirements from the HMI computer, especially if a proprietary
communications protocol to the SCADA system is used.

For this topology, a powerful HMI computer is clearly required if large numbers of IEDs are to
be accommodated.

Figure 1 HMI based hardware topology

In practice, costs usually dictate the use of a standard PC, and hence there will be limitations on substation size that it
can be applied to because of a resulting limit to the number of IEDs that can be connected.

The other important issue is one of reliability and availability there is only one computer that
can control the substation and therefore only local manual control will be possible if the computer fails
for any reason.

Such a topology is therefore only suited to small MV substations where the consequences of computer failure
(requiring a visit from a repair crew to remedy) are acceptable. Bay Modules are not used, the software for control and

interlocking of each substation bay runs as part of the HMI computer software.

Substation control system HMI computers (photo credit: processautomationinsights.com)

Go back to Hardware Topologies

RTU based Topology

This topology is an enhancement of the HMI topology and is shown in Figure 2. A microprocessor based RTU is
used to host the automation software, freeing the HMI computer for operator interface duties only.
The HMI computer can therefore be less powerful and usually takes the form of a standard PC, or for not-normally
manned substations, visiting personnel can use a portable PC.

Figure 2 RTU based topology

The RTU is purpose designed and can house one or more powerful microprocessors. A greater number of
I/O points can be accommodated than in the HMI topology, while the possibility exists of hosting a wider variety
of communication protocols for IEDs and the remote SCADA connection.
Bay Modules are not required, the associated software for interlocking and control sequences is part of the RTU
software.

The MOSCAD Remote Terminal Unit (RTU) provides a data collection and processing unit with the intelligence required to
operate in sophisticated Supervisory Control and Data Acquisition (SCADA) systems. Communications via two-way radio,
digital microwave radio, Ethernet and wirelines is supported (photo credit: rlandkabaena.blogspot.fr)

Go back to Hardware Topologies

Decentralised Topology
This topology is illustrated in Figure 3. In it, each bay of the substation is controlled by a Bay Module, which houses

the control and interlocking software, interfaces to the various IEDs required as part of the control and protection
for the bay, and an interface to the HMI.
It is possible to use an HMI computer to take local control of an individual bay for commissioning/testing and
fault finding purposes.
The amount of data from the various substation I/O points dictates that a separate SCADA interface unit is provided
(often called an RTU or Gateway), while it is possible to have more than one HMI computer, the primary one being
dedicated to operations and others for engineering use.

Figure 3 Decentralised topology

Optionally, a remote HMI computer may be made available via a separate link. It is always desirable in such schemes
to separate the realtime operations function from engineering tasks, which do not have the same time-critical
importance.
The connection between the various Bay Modules and the HMI computer is of some interest.
Simplest is the star arrangement of Figure 4(a). This is the least-cost solution, but suffers from two disadvantages.
Firstly, a break in the link will result in loss of remote control of the bay affected; only local control via a local
HMI computer connected to the bay is then possible.
Secondly, the number of communication ports available on the HMI computer will limit the number of Bay Modules.

Figure 4 Methods of hardware interconnection

Of course, it is possible to overcome the first problem by duplicating links and running the links in physically separate
routes. However, this makes the I/O port problem worse, while additional design effort is required in ensuring cable
route diversity.
An alternative is to connect the Bay Modules, HMI computer and SCADA gateway in a ring , as shown in Figure
4(b).

By using a communication architecture such as found in a LAN network, each device is able to talk to any other device
on the ring without any message conflicts. A single break in the ring does not result in loss of any facilities.
The detection of ring breakage and re-configuration required can be made automatically. Thus, the availability and
fault tolerance of the network is improved. Multiple rings emanating from the HMI computer can be used if the number
of devices exceeds the limit for a single ring. It can be easier to install on a step-by-step basis for retrofit applications,
but of course, all these advantages have a downside.

The cost of such a topology is higher than that of the other solutions , so this topology is reserved for
situations where the highest reliability and availability is required i.e. HV and EHV transmission
substations.

Redundancy can also be provided at the individual device level. Relays and other IEDs may be duplicated, though this
would not be usual unless required for other reasons (e.g. EHV transmission lines may be required to have duplicate
main protections this is not strictly speaking duplication of individual devices which would require each individual
main protection to have two identical relays voting on a 1 out of 2 basis).
It is usual to have more than one operators HMI , either for operational reasons or for fault-tolerance. The system
computer may be duplicated on a hot-standby or dual-redundant basis, or tasks may be normally shared
between two or more system computers with each of them having the capability of taking over the functions of one of
the others in the event of a failure.
The total I/O count in a major substation will become large and it must be ensured that the computer hardware and
communication links have sufficient performance to ensure prompt processing of incoming data.
Overload in this area can lead to one or more of the following:
1. Undue delay in updating the system status diagrams/events log/alarm log in response to an incident
2. Corruption of system database, so that the information presented to the operator is not an accurate
representation of the state of the actual electrical system
3. System lockup

TM 1703 Distributed I/O Module. Applications for the TG5700 RTU with TM 1703 I/O extend to Condition
Based Monitoring, Transformer Monitoring and local Bay Controller Unit (photo credit: pacw.org)

As I/O at the bay level, both digital and analogue will typically be handled by intelligent relays or specialised IEDs, it is
therefore important to ensure that these devices have sufficient I/O capacity. If additional IEDs have to be provided
solely for ensuring adequate I/O capacity, cost and space requirements will increase.

There will also be an increase in the number of communication links required.

A practical specification for system response times is given in Table 1. Table 2 gives a typical specification for the
maximum I/O capacities of a substation automation system.
Table 1 Practical system response times for a substation automation scheme
Signal Type

Response Time to/from HMI

Digital Input

1s

Analogue Input

1s

Digital Output

0.75s

Disturbance Record File

3s

Table 2 Typical I/O capacities for a substation automation system

I/O Type

Capacity

Digital Input

8196

Digital Output

2048

Analogue Input

2048

Analogue Output

512

A significant problem to be overcome in the implementation of communication links is the possibility of electromagnetic
interference. The low voltage levels that are used on most types of communication link may be prone to interference
as a result.
Careful design of the interfaces between the devices used and the communication bus, involving the use of optocouplers and protocol converters, is required to minimise the risk.
Care over the arrangement of the communication cables is also required. It may also help to use a
communication protocol that incorporates a means of error detection and/or correction. While it may not be possible
to correct all errors, detection offers the opportunity to request re-transmission of the message, and also for statistics
to be gathered on error rates on various parts of the system.
An unusually high error rate on a part of the communication system can be flagged to maintenance crews for
investigation.
Go back to Hardware Topologies
Reference // Network Protection and Automation Guide Areva