See discussions, stats, and author profiles for this publication at: https://www.researchgate.net/publication/224408154

Communication Protocols and Networks for Power Systems – Current Status and

Future Trends

Conference Paper · April 2009

DOI: 10.1109/PSCE.2009.4840174 · Source: IEEE Xplore

CITATIONS

63

READS

1,417

3 authors, including:

Salman Mohagheghi

Colorado School of Mines

93 PUBLICATIONS   2,323 CITATIONS   

SEE PROFILE

J. Stoupis

24 PUBLICATIONS   300 CITATIONS   

SEE PROFILE

All content following this page was uploaded by Salman Mohagheghi on 09 February 2014.

The user has requested enhancement of the downloaded file.

1

Abstract—Minimizing implementation time and manual configuration, as well as straightforward upgradability are the key requirements of efficient substation automation systems. For larger utilities this often necessitates achieving interoperability between different devices from multiple vendors. Since the early 1990’s it was noticed that the speed of advances in communication technology seemed to overpass its power system counterpart, which called for more adaptability by substation automation systems and higher independence from the underlying communication technology. The natural shift in the industry from proprietary communication protocols to open access standards was therefore further accelerated and was directed towards more advanced solutions that provide an interoperable and future proof environment. In order to be able to respond to these concerns, IEC 61850 was proposed as a future proof, adaptable communication protocol, capable of providing interoperability in a multi-vendor environment and with a highly advanced object oriented modeling structure. The migration from legacy protocols and de facto standards such as Modbus, DNP3, and IEC 60870-5 has already started and it seems likely that it will continue at a steady pace in the future. In addition to the efforts to provide an advanced solution for substation automation systems, there is also a need for extending the “automation” benefits to beyond the substations either downstream, at the feeder level or upstream, at a higher level of network management. The objective of this paper is to provide an overview of the current status of communication networks for substations using IEC 61850, and also discuss the possible future trends for extending the scope of the standard and using its capabilities for other applications within the distribution system.

Index Terms—Communication networks, distribution system, communication protocols, IEC 61850, TASE.2, DNP3, Modbus, interoperability.

I. NOMENCLATURE

ACSE- Application Control Service Element ACSI- Abstract Communication Service Interface CID- Configured IED Description CRC- Cyclic Redundancy Check GOOSE- Generic Object Oriented Substation Event GSSE- Generic Substation State Event HMI- Human Machine Interface ICCP- Inter Control Center Communications Protocol ICD- IED Capability Description IED- Intelligent Electronic Device

The authors are with ABB Inc., US Corporate Research Center, Raleigh,

NC, 27606 USA (email: salman.mohagheghi@us.abb.com, james.stoupis @us.abb.com, zhenyuan.wang@us.abb.com).

MMS- Manufacturing Message Specification OSI- Open Systems Interconnection PDU- Protocol Data Unit PMU- Phasor Measurement Unit RBE- Report by Exception SA- Substation Automation SCD- Substation Configuration Description SCL- Substation Configuration Language SSD- System Specification Description SV- Sampled Values TASE- Tele-control Application Service Element

II. INTRODUCTION

OMMUNICATION protocols and standards were introduced to the industry since late 1970’s. These

standard protocols were quickly adopted for power system applications and gradually replaced their proprietary counterparts. Designed primarily to ensure interoperability between multi-vendor systems, these protocols also simplify integration and commissioning of data communication networks, reduce the installment costs, and allow for independent testing and validation, which in turn leads to more efficient designs. In addition, communication systems designed in accordance with these standards can be more easily upgraded or modified in the future. This is especially important, since the advances and innovations in the field of communication networks often outpace the frequency of modifications in the power system infrastructure. Therefore, the designed communication network must be adjustable to new power system automation designs with the least amount of effort possible.

A typical power system is an interconnected network that connects the distribution system, the transmission system, and the generation units. Ideally, all sections of such a network must be able to communicate with one another, and share all the data. However, in practice, this does not seem practical due to the sheer volume of the data involved, limitations on the available communication channels, as well as security concerns. Therefore, data sharing and communication systems have often been designed to cover subsystems rather than the whole power grid. In a typical power system several standard communication protocols exist, each one covering certain domains and a specific group of data. Figure 1 illustrates an example of some communication protocols used in a typical power system [1].

Communication Protocols and Networks for Power Systems-

Current Status and Future Trends S. Mohagheghi, Member, IEEE, J. Stoupis, Member, IEEE, and Z. Wang, Member, IEEE

C

2

Distribution substations constitute the heart of the distribution system and depending on their size, contain tens to hundreds of different protection and control devices, not necessarily from the same manufacturer. Various standard protocols such as IEC 60870-5, DNP3 and IEC 61850 are used to make coordination and data sharing between these devices possible. A more concise portion of this data needs to be sent to the higher level of the hierarchy, which includes the control centers. In addition to communication with the control centers, distribution substations often need to monitor the data from the feeders and load points connected downstream, in order to improve the protection and control decisions.

Fig. 1. Typical communication protocols used in a power system.

Control centers on the other hand manage the stability, security and reliability of the power system as a whole, and in order to achieve this, among other things, they need to have access to the vital information from the distribution side. In addition, these control centers communicate with one another, as well as with the generating units and market participants if applicable. Various communication protocols exist that can be used to achieve this.

The purpose of this paper is to present an overview of some of the most common communication protocols and standards used inside and outside the distribution substation. Also, future trends and possible extensions to these protocols are briefly discussed.

The rest of the paper is organized as follows. Section III of the paper provides a brief overview to two examples of legacy protocols used in the power industry: Modbus and DNP3, where the latter is currently the predominant standard used in distribution substations in North America. A general introduction to IEC 61850 as the next generation communication protocol is presented in section IV of the paper. Common practices for communication protocols

beyond substations appear in section V. In section VI, some of the future trends and possible extensions to the usage of IEC 61850 are discussed. Finally, concluding remarks are provided in section VII of the paper.

III. LEGACY PROTOCOLS

A. Modbus

Modbus transmission protocol was developed by Gould Modicon (now Schneider) for process control systems, and has been industry’s serial de facto standard since 1979. It is an application layer messaging protocol that is positioned at level 7 of the OSI model [3] and is used for client/server communication between devices connected to the same network. Modbus messages are of either query/response type or broadcast/no response type, which in either case can only be initiated by the client, in other words RBE is not supported (except for Modbus TCP). Every type of device (PLC, HMI, control panel, driver, I/O device) can use Modbus to initiate a remote operation.

In general, different transmission protocols exist for implementing Modbus protocol [2]: • Asynchronous Serial Transmission: for serial connections

(over wire RS-232, 422 or 485, fiber or radio). Two different transmission modes exist, Modbus RTU, a compact, binary representation of the data, which is faster and is used for normal operation (hex); and Modbus ASCII, which is human readable, and more verbose, and is used for testing purposes.

• TCP/IP over Ethernet • Modbus Plus: also referred to as Modbus+ or MB+,

which is currently proprietary to Modicon. Using gateways these different implementations can

coexist in a single communication network [4] (Fig. 2).

Fig. 2. Modbus implementation on LAN.

Modbus supports four main data types: read only 1-bit

inputs and 2-byte input registers which can be provided by an I/O system, and 1-bit discrete outputs (coils) and 2-byte

3

holding registers, which are read/write enabled and can be altered by an application program.

Modbus protocol defines a simple PDU independent of the underlying communication layers [4]. A typical Modbus Application Data Unit (ADU) is shown in Fig. 3 [2]. The address field contains the address of the server. The function field includes the code of the function to be performed by the server. Examples of these functions are coil control commands, reading the input status of coils, register control commands, diagnostics tests and reports, and reset commands. The information that the server might need to perform the requested function is provided in the data field, and finally the last 2 bytes contain the CRC bits.

Protocol Data Unit (PDU)

Application Data Unit (ADU) 1 Byte 1 Byte Variable 2 Bytes

Address Field

Function Field Data Field Error Checking

Field Fig. 3. Typical Modbus ADU.

For asynchronous Modbus and Modbus+ the ADU in Fig.

2 is directly mapped to the physical layer, while in Modbus/TCP it is first passed through the transport and network layers (Fig. 4) [3].

Fig. 4. Mapping Modbus onto the OSI model.

B. DNP3

DNP3 is a telecommunications standard that defines communications between client stations, RTUs and other IEDs. It was developed by GE based on the early parts of IEC 60870-5. They made it public in 1993, and the ownership was given to the newly formed DNP Users Group. It was originally designed for SCADA applications, i.e. acquisition of information and sending control commands between physically separate computer devices, however, today DNP3 is widely used in electrical, water infrastructure, oil and gas, security and other industries in North America, South America, South Africa, Asia and Australia (cf. IEC 60870-5-101/104 [5] which is mostly confined to electrical industries in Europe and more or less provides the same functionalities as DNP3).

The purpose of DNP3 is to transmit relatively small packets of data in a reliable manner with the messages involved arriving in a deterministic sequence. Figure 5 depicts the overall messaging sequence in DNP3 [2]. Application data

may be any size, even zero, for example for a command. This is broken into multiple Application PDU (APDU), or Fragments, with a size limit of 2048 bytes. Breaking longer messages into multiple packets helps optimize error control. The APDU is further broken down into multiple Transport PDUs (TPDUs), with a size limit of 250 Bytes to fit into the Data Link frame. Link layer header and the CRC bytes are added to the TPDU, and the resultant Link PDU (LPDU or frame) is passed on to the physical layer, which transmits 8 bits of data plus an additional bit to indicate start/stop of each sequence.

Fig. 5. Structure of a DNP3 message.

The original physical layer consisted of RS232, for short distance point-to-point communications, RS 422, which is a bidirectional extension of RS232 for industrial environments, or RS485, for multipoint communications. However, today’s operating environments have changed so that organizations can operate over larger geographic areas. This has pushed DNP3 to define a method involving the use of internet protocol suite for the transport and network layers, and the Ethernet physical layer. The idea of carrying DNP3 over a network environment involves encapsulation of the data frames from the DNP3 data link layer within the transport layer frames of the internet protocol suite.

As it is shown in Fig. 6 [2], pseudo-transport and data link layers of DNP3 remain in the stack and act above the transport/network/data link layers provided by TCP/UDP, IP and Ethernet LAN. This is because these are essential elements of the DNP3 layers that are required to operate together, for instance addressing and error detection in the data link frame. In such an environment, TCP is strongly

4

preferred for LANs and is necessary for WANs. UDP, on the other hand, may be used for highly reliable LANs, or for broadcast messages [2].

In addition to the traditional client/server communication mode, DNP3 also supports peer-to-peer, multi-server, multi-master and hierarchical mode communications (using data concentrator) [6]. It also provides polled and RBE modes of operation.

Fig. 6. DNP3 over Ethernet.

IV. COMMUNICATION WITHIN THE SUBSTATION- IEC 61850

IEC 61850 is a standard recommended by IEC for the design of substation automation systems [8]. It divides inter-substation communication into three levels: process level including the I/O devices, intelligent sensors and actuators, bay/unit level including the protection and control IEDs, and the substation level, including the substation computer, operator’s desk and the interfaces with outside the substation. All the communications within and between these levels are covered in the standard (Fig. 7). Although in its current format, the standard does not cover protection data exchange between the bay and remote protection, nor control data exchange between substation and remote control center.

Fig. 7. Substation automation topology based on IEC 61850.

A. Object Oriented Model

In the IEC 61850 environment, protection and control functions are broken into smaller units called Logical Nodes (LN). These virtual units are in fact the objects defined in the object oriented context of the standard, and present one of the most important advantages of the standard over legacy protocols. There are a total of 92 LNs defined in IEC 61850 that correspond to various protection, protection related, control, metering, and monitoring functions as well as the physical components such as the transformers and breakers. Figure 8 illustrates an example where multiple LNs interact with one another to perform three functions: generic automatic function, breaker control function and voltage control function [8].

Fig. 8. Example of logical nodes for generic automatic function, breaker control function and voltage control function (IHMI: human machine interface, CALH: alarm handler, CILO: interlocking, GAPC: generic automatic process control, GGIO: generic input and output, CSWI: circuit breaker controller, XCBR: circuit breaker, XSWI: isolator, ATCC: automatic tap changer controller, YLTC: tap changer)

Each LN can have a few or up to 30 data objects, each of which belonging to a Common Data Class (CDC). Each data object in turn has a few or more than 20 data attributes. The LNs can be on any of the three levels defined for substation automation. It should be noted that each physical device such as an IED can host several logical nodes depending on its functionality. These LNs are grouped into logical devices (LD) which are defined in the context of the physical device, with each physical device containing at least one logical device [8] (Fig. 9).

Fig. 9. Data structure in IEC 61850.

5

IEC 61850 defines an abundance of services that act upon the data objects of the LNs. These services not only cover the traditional control/read/write commands, but they also cover new and expanded services for grouping the data objects, reporting and logging, as well as transmitting the fast messages, i.e. GOOSE and GSSE [8] (Fig. 10).

Fig. 10. LN, LD and the communication services.

B. Communication Services

The communication services and data models are defined in section 61850-7-2 of the standard. The Abstract Communication Service Interface (ACSI) specifies the models and services used for access to the elements of the domain specific object model. ACSI is a network independent interface that defines the semantic of the service models with their attributes, and describes what these services provide. The abstract nature of ACSI is necessary to make the SA system compatible with the fast advances in the communication technology. In other words, the SA specific data model needs to be separate from the communication technology.

The syntax and encoding of the messages are defined in Specific Communication Service Mapping (SCSM). For example, IEC 61850-8-1 is a SCSM for mapping of services to MMS. Figure 11 illustrates how these communication stacks and interfaces are related.

Fig. 11. Data model and communication services- mapping to the OSI layered model

In addition to client/server services by mapping to MMS stack, the standard provides peer-to-peer services for transmitting Sampled Values (SV) and GOOSE messages (Fig. 12).

SV represents quantities digitized at the source to be transmitted to the substation. These quantities come from modern low energy voltage and current sensors which gather information from the primary power system. IEC 61850-9-1 and 61850-9-2 define two mappings for SV over serial unidirectional multi-drop point to point link and SV over ISO/IEC 8802-3.

GOOSE messages on the other hand are used to model the transmission of high priority information like trip commands or interlocking information. The model is based on cyclic and high-priority transmission of status information. Information like a trip command is transmitted spontaneously and then cyclically at increasing intervals. GOOSE uses a multicast exchange.

Fig. 12. Client/server and peer-to-peer communication modes in IEC 61850.

C. Substation Configuration Language (SCL)

Substation Configuration Language (SCL) is an eXtensible Markup Language (XML) based language used by IEC 61850 for representation and configuration of the SA system. It includes data representation for all the devices in the substation, all the logical nodes along with their data objects and attributes, as well as communication systems and capabilities. The representation of the IEDs and the SA functions as a SCL files is one of the most prominent features of the standard that enhances the communication capabilities between different IEDs towards a complete interoperability. Some of the major benefits of SCL modeling include [9]: • Enabling automatic configuration of IEDs using offline

development tools, significantly reducing the cost and effort of IED configuration.

• Enabling the sharing of IED configuration among users and suppliers.

• Enabling offline configuration of IEC 61850 applications without requiring a network connection to the IED for client configuration.

6

Part IEC 61850-6 of the standard defines four types of SCL files : • IED Capability Description (ICD): describes the

capabilities of the IED, and comprises of an IED section, data type templates, logical node type definitions, optional communication section and an optional substation section.

• System Specification Description (SSD): describes the specifications of the related system, and comprises of a substation description section, data type templates, and logical node type definitions.

• Substation Configuration Description (SCD): describes the detailed power system, and comprises a description section for each IED, a communication configuration section and a substation description section.

• Configured IED Description (CID): is used to communicate data and settings between an IED and its configuration tool. It includes a communication section that contains the current address of the IED.

D. Comparison with Legacy Protocols

Although IEC 61850 is often referred to as a more advanced communication protocol, with its object oriented modeling capabilities and detailed communication interfaces defined, it tends to be more than just a protocol in the traditional sense. Nevertheless, it has major advantages compared to the legacy protocols, such as DNP3 and IEC 60870-5-101/104. Some of the major advantages of IEC 61850 are listed below [10]: • Similar to legacy protocols, it allows vendors to create

application specific extensions, but it also provides close to 100 logical node classes with 2000+ data objects/attributes.

• It is more easily extendable than legacy protocols. • It uses hierarchical names (see Fig. 9) instead of indexed

addressing. • Similar to DNP3 and IEC 60870-5 (and unlike Modbus)

it supports quality attribute, time stamp, and cause of transmission.

• The data (LNs, data objects and attributes) are more self descriptive.

• It is more flexible in parameter setting control, and allows the user to define, change and edit the parameters at any time. This capability is limited in legacy protocols.

• It provides means to transmit substation events (GOOSE) and sampled values.

• It allows the user to access the complete information hierarchy of all objects by obtaining the directory. This service is limited in 60870-5-103 and does not exist in DNP3.

• It is more powerful in providing the definitions of operational objects and communication service related objects.

• It is more flexible in selecting the data for reporting, enabling/disabling the communication control objects, and changing reporting/logging behavior.

• Complete description of device configuration is available in XML format, instead of hardcopy documents (this feature is under development for DNP3).

• It fully supports vendor independent engineering tools for development.

• IEC 61850 is also open for future service systems, such as HTTP, COBRA.

However, it should be noted that although IEC 61850 has major advantages over Modbus, DNP3 and IEC 60870-5 on the data side, it also adds a lot of overhead for implementation. It is more complicated than the legacy protocols, so it may take some time to be fully adopted by the industry. Current estimates indicate that the market penetration of the standard has increased during the past few years [10], but the authors believe that at least in the North American market it will not overpass DNP3 in the immediate future. Recent surveys indicated that DNP3, especially LAN based DNP3, is the leading protocol for planned usage in the future within the substation and for communication from the substation to the external network/host [11].

V. COMMUNICATION OUTSIDE THE SUBSTATION

A. Upstream- ICCP

Traditionally, utilities used to rely on proprietary protocols to exchange real-time data. Gradually, a need was felt for migrating towards an open access standard protocol to allow for better disturbance detection and reconstruction, improved modeling capabilities and enhanced secure operation. The result was two standards, referred to as the Tele-control Application Service Element (TASE), recommended by the IEC TC-57 WG-07 [12]. A quick implementation called TASE.1 was developed in 1992 in order to meet the European Common Market requirements. Later, TASE.2 was developed as a long term development of a more comprehensive protocol. TASE.2 is also referred to as Inter-Control Center Communication Protocol (ICCP) [13].

ICCP sits in the upper sub-layer of layer 7 in the OSI reference model and uses MMS for the required messaging services. MMS specifies mechanics of naming, listing and addressing variables, and mechanics of message control and interpretation, while ICCP specifies control center object formats, and methods for data requests and reporting.

ICCP can operate over either an ISO compliant transport layer or a TCP/IP transport layer; although, TCP/IP over Ethernet (802.3) seems to be the most common (Fig. 13) [13],[14].

ICCP is based on client/server models. All data transfers originate with a request by a control center to another control center that owns and manages the data. A control center can be both a client and a server. The types of requests can be single requests, requests for periodic transfers, or requests for RBE only. ICCP might operate over a point-to-point link or over a router based WAN. The common implementation architecture is that the ICCP is used over Ethernet and that

7

WAN connectivity for remote access is supplied through the use of an external router [14].

Fig. 13. ICCP mapping onto the OSI stack.

Multiple associations may be established from a client to multiple control center servers [13]. It may also be established to the same control center for the purpose of providing associations with different Quality of Service (Fig. 14).

Fig. 14. Multiple associations for ICCP clients.

The server checks each client request to ensure that the particular client has access rights to the data or capability requested. Access control is provided through Bilateral Tables which are defined for each client/server association and provide execute, read/write, read only, no access for each item.

There are two types of object models in ICCP [13] (Fig. 15): • Server Objects: Defined in IEC 60870-6-503. Can be

either Operations (client-initiated) or Actions (server-initiated, e.g. due to a change in the status of a breaker). These are the internal objects that are required to implement the ICCP protocol.

• Data Objects: Defined in IEC 60870-6-802. Supported data types include control messages, status, analogs, schedules, text and simple files. New data objects can be defined as well. These are the external objects and are not required for implementing the protocol.

Using ICCP, applications at different control centers, written by different vendors but conforming to the protocol, can interoperate to share data, control utility devices, output information messages, or execute remote programs. Each vendor implementing ICCP is free to choose the API most suitable for their products. This is a local implementation issue and is not addressed in ICCP.

Fig. 15. ICCP objects.

In the US, ICCP networks are widely used to tie together groups of utility companies typically a regional system operator with transmission utilities, distribution utilities and generators [14]. Regional operators may also be connected together to coordinate import and export of power between regions across major inter-ties. In addition, ICCP can also be used to exchange information between applications located within a single control center, for instance between the control center’s EMS and a historian or SCADA system [14] (Fig. 16).

Fig. 16. ICCP implementation over WAN and LAN.

B. Downstream- DNP3

DNP3 (or IEC 60870-5 for European implementations) can be used for communication between the substation and the

8

control center. The DNP3 implementation on TCP/IP allows for transferring the data over WAN.

DNP3 is also the main protocol currently used to communicate with feeder automation equipment. This could be communication between the substation and the feeder devices or between the SCADA system (control center) and the feeder devices. The RBE feature is extremely useful for feeder applications, especially when utilities do not want to continually poll the feeder devices due to cost of data transmission.

Currently, DNP3 is the leasing protocol for communications outside the substation, and will remain the leading protocol for planned usage in the future [11].

VI. FUTURE TRENDS

A. IEC 61850 beyond Substations

Although standard protocols exist that cover communications beyond substations, it is generally believed that the capabilities of IEC 61850 can be potentially used to improve these applications. 1) Feeder Communication

During the recent years, more efficient operation, reduction in projected costs and improved reliability have motivated electric utilities to increase the level and scope of automation of their assets. Although IEC 61850 addresses issues related to substation automation, the same ideas and capabilities can be utilized equally well for beyond substations, such as feeders and distributed generation and storage units.

Extending the IEC 61850 standard to feeders ensures the interoperability of all components participating in distribution automation, from the distribution substation to the point of interface with the end users. This extension requires including some or all of the following components in the IEC 61850 framework: • Switched capacitor banks and static VAR compensators • Voltage regulation devices • Network protectors • Feeder transformers • Feeder control devices, switches and reclosers • Power quality enhancement devices, such distribution

FACTS (DFACTS) devices and voltage sag correctors • Other power electronic based devices used in the

distribution systems • Protection systems, fuses and relays along the feeders • Fault detectors, indicators, locaters • Information exchange with metering devices deployed

along the distribution feeders, e.g. advanced metering infrastructure (AMI)

Extension of IEC 61850 to the feeder can be in the form of using the same logical nodes defined in the standard, or applying the same messaging techniques such as GOOSE messages for fast exchange of protection and control, and sampled values for transmitting the measured values from the

feeder to the substation. Obviously, achieving this requires a widespread

communication network and the required infrastructure that links the feeder devices to the HMI in the substation. This will necessitate initial investment; however, it will prove to reduce the overall costs in the long run due to improved reliability and operation. 2) Communication with Control Centers

IEC 61850 specifies that connection to the remote control center is beyond its scope [8]. Expanding the standard to include the link to the control centers is technically possible; although, it would require having a large amount of additional logical connections between the substation and the control center, and possibly defining additional logical nodes. While defining new logical nodes does not introduce any technical complications, implementing additional logical connections might lead to inefficient performance.

It is generally believed in the industry that this integration can be more efficiently done in two ways: • Map IEC 61850 data model content to a traditional

SCADA protocol such as DNP3 or IEC 60870-5 [15]. This does not pose a technical difficulty, but might lead to some loss of information or speed, for instance when mapping GOOSE messages.

• Provide a proxy server for IEC 61850 data in the substation. This provides for a gateway in the substation providing a single point of access for the 61850 data model content [15]. Section 61850-7-1 of the standard shows how logical device modeling can be utilized to map multiple physical devices into a single physical device to act as a proxy or gateway or multiple devices. In this case, the proxy/gateway device functions as a data concentrator and can direct requests/responses between substation and the control center. This virtual interface to the outside world can be a telecontrol interface (TCI) to a remote control center, or a telemonitoring interface (TMI) to remote engineering workplace for monitoring and maintenance purposes.

B. Peer-to-Peer Communication

GOOSE messages are one of the unique features provided by IEC 61850 that allow fast messages between different IEDs in a peer-to-peer format. While the standard only considers intra-substation communications as the scope for GOOSE, it is possible to employ the concept for applications beyond substations.

One of the examples is using GOOSE messages for fast transfer of sensitive information between protective relays (e.g. trip commands or outage detection) or PMUs (e.g. over/under-voltage or current flows close to stability/thermal limits) at the transmission level. This information can be extremely helpful for improving the reliability and security of the overall power system.

Naturally, such a scheme would require using the current communication infrastructure or maybe expanding its bandwidth capabilities in order to ensure that the signals are

9

sent and received within the required timeframe. In general, for a large size power system, this means a WAN that covers the whole geographical area. Possible transmission media are fiber optics and microwave.

In one possible scheme [16], once the GOOSE message is generated and sent, it is picked up by a centralized processor, which can be a high performance computing unit that interprets the GOOSE message, identifies the contingency, performs calculations and determines a remedial action, which is then transmitted to the communication network and is received by other IEDs. Figure 17 illustrates a schematic diagram of this approach.

Fig. 17. Structure for peer-to-peer communication between transmission system devices using GOOSE messages.

Of course, variations to this approach can also exist. For instance, it is possible for the IEDs to have their local interpreters that receive the GOOSE message and based on the information available locally make a decision. This scheme removes the need for having a centralized processor, but at the same time places more computational burden and requires data for local calculations.

VII. SUMMARY

Standard protocols were adopted by the industry to pave the way for efficient substation automation systems. The need for more platform-independent and interoperable protocols led to the introduction of IEC 61850 standard for communication networks and systems in substations, which was proposed as a future proof and adaptable communication protocol, capable of providing interoperability in a multi-vendor environment and with a highly advanced object oriented modeling approach. In addition to the efforts to provide an advanced solution for substation automation systems, there is also a need for extending the “automation” benefits to beyond the substations. This paper presented an overview of the legacy protocols used mostly in the North American markets, as well as an introduction to the communication networks for substations using IEC 61850 as the next generation substations. Also, possible future trends

for extending the scope of the standard and using its capabilities for other applications within the distribution system were discussed.

VIII. REFERENCES [1] International Communication Standards with regard to Power Automation,

[Online] available at grouper.ieee.org/groups/1525 /CIGRE34.07/Symbols/symbols.ppt

[2] G. Clarke and D. Reynders, Modern SCADA Protocols- DNP3, IEC 60870-5 and Related Systems, Burlington, MA: Elsevier, 2004.

[3] Modbus Application Protocol Specification V1.1b, Modbus-IDA, December 2006, pp. 1-51, [Online] available at http://www.modbus-IDA.org.

[4] Modbus Messaging on TCP/IP Implementation Guide V1.0b, Modbus-IDA, October 2006, pp. 1-45, [Online] available at http://www.modbus-IDA.org.

[5] IEC 60870-5- Telecontrol Equipments and Systems- Part 5: Transmission Protocols, IEC Std. 2002.

[6] K. Curtis, “A DNP3 Protocol Primer,” DNP Users Group, March 2005, pp. 1-8, [Online] available at http://www.dnp.org.

[7] Technical Report, “Modbus and DNP3 Communication Protocols,” Triangle Microworks, Inc, [Online] available at www.TriangleMicroWorks.com.

[8] IEC 61850- Communication Networks and Systems in Substations, IEC Std. 2003.

[9] R. E. Mackiewicz, “Overview of IEC 61850 and Benefits,” in Proc. IEEE PSCE, Oct./Nov. 2006, pp. 623-630.

[10] K. Schwarz, “Comparison of IEC 60870-5-101/-103/-104, DNP3, and IEC 60870-6-TASE.2 with IEC 61850,” February 2002, [Online] available at www.nettedautomation.com.

[11] “The World Market for Substation Automation and Integration Programs in Electric Utilities: 2005-2007,” Newton-Evans Research, September 2005.

[12] IEC 60870-6- Telecontrol Equipments and Systems- Part 6: Telecontrol Protocols Compatible with ISO Standards and ITU-T Recommendations, IEC Std. 2004.

[13] T. Saxton, D. Ambrose, and F. Kendall, “ICCP User Guide,” October 1996, [Online] available at www.sisconet.com/downloads/usrguid5.doc.

[14] D. Becker, “ICCP (TASE.2) Security Enhancement,” EPRI, October 2003, [Online] available at http://www.epriweb.com/public.

[15] A.C. West, SCADA mailing list communication, August 2008. [16] P. Arons and H. Falk, “Centralized Remedial Action Scheme (C-RAS)

Using Emerging Telecommunication, Protection Technologies, and OSIsoft PI,” presented at i-PCGRID workshop, San Francisco, CA, March 2008.

IX. BIOGRAPHIES

Salman Mohagheghi (S’99, M’07) received the B.Eng. from University of Tehran, Iran and M.Sc. from Sharif University of Technology, Tehran, Iran, both in Power Electrical Engineering in 1998 and 2001 respectively. In 2006 he graduated with PhD in Electrical Engineering from Georgia Institute of Technology, Atlanta, GA, USA, where he later joined as a Postdoctoral Fellow. He is currently a Senior R&D Engineer at ABB Inc, US Corporate Research Center, Raleigh, NC, USA. His current research focuses on communication networks in power systems, Smart Grid applications and distribution automation.

James Stoupis (M’91) is a Principal Consulting R&D Engineer in the Power Technologies Department for ABB’s US Corporate Research Center located in Raleigh, North Carolina. Jim has been employed at USCRC for 12 years, and his research has been focused in the areas of distribution and feeder automation, wireless communications, power system protection and control, and event detection and classification. Jim holds a BSEE from the University of Illinois at Urbana-Champaign and an MSEE from Virginia Tech.

Zhenyuan Wang (M’2000) joined ABB Corporate Research in Raleigh, North Carolina in 2000, where he is currently a Principal Consulting R&D Engineer. His research interests include electric power equipment condition monitoring/assessment/diagnosis, system monitoring, control and automation for a smart grid. His experiences include asset management IT applications in the electric power industry, power system transient analysis, substation/distribution automation, and data integration/warehousing/mining applications.

View publication statsView publication stats