GOOSE message applications for substation protection and control

The IEC 61850 standard for communication networks and systems for power utility automation introduced a number of concepts which offer opportunities to enhance the design and implementation of substation automation systems. Arguably the most important aspect of the standard is the generic object oriented substation event (GOOSE) message service that enables new applications and introduces improved methods of implementing established designs. This study describes the application of GOOSE messaging, demonstrating the benefits and outlining the applications which it enables. A case study is presented which demonstrates these benefits and offers an insight into the types of applications enabled by GOOSE services.

Go to the profile of Craig McTaggart
Sep 04, 2017
Upvote 0 Comment

Author(s): Craig McTaggart


Prior to the publication of the IEC 61850 standard in 2003, inter-device communications had used a variety of standard and vendor proprietary protocols, and a variety of communications interface standards such as RS232, RS485 and latterly Ethernet. This led to complex, manual engineering methods, difficulty in ensuring interoperability of devices and limitations on the application of functionality due to the absence of standardisation. The IEC 61850 standard addressed these issues by introducing the following key concepts:

  1. The use of a standardised model for describing real devices.
  2. The definition of a set of abstract communication services to exchange information.
  3. The definition of a language to describe intelligent electronic device (IED) capabilities and how IEDs are configured.
  4. The definition of how to implement these services, mapping them into specific protocols.

The ability of each protection or control device to self-describe its capabilities using a standard model in a standard language, and for its modelled data to be transferred between devices using standard mapping to standard protocols is a very powerful concept. This article focuses on one of the standard communication mappings, Generic Object-Oriented Substation Event (GOOSE), and the benefits it offers to substation protection and control systems. By describing the end-to-end process for the design, configuration and implementation of GOOSE applications, the advantages of applying GOOSE will be highlighted.

The IEC 61850 standard

The IEC 61850 standard is a lengthy and comprehensive suite of documents covering all aspects of utility inter-device communications. Much of the standard provides details for manufacturers to design their devices to implement the features of the standard. The following sections briefly describe the most relevant parts of the standard for applications engineers.

Modelling of functions

The vision of IEC 61850 is that functions, protection or control for example, can be distributed and implemented across different devices, or IEDs, as required by the scheme designer. The standard introduces three different levels applicable to substations:

  • Station level is envisaged as one or more devices handling functions such as station-level interlocking, remote control and monitoring and a local HMI.
  • Bay-level devices are those that handle protection, control and monitoring functions specific to individual bays [1].
  • Process-level devices are intended to be located at, or integrated with, primary equipment and may consist of remote I/O, sensors and analogue to digital interfaces.

To enable functions to be distributed among physical devices which may be from different vendors, the functions must be implemented in a standard way. These functions, at the lowest level, are named logical nodes (LNs). Each physical device (IED) hosts one or more LNs (a typical device will host tens of LNs) which may be grouped into logical devices (LD) within the IED. LDs are a convenient mechanism for simplifying the structure of the data model, for example all protection LNs may be grouped in a ‘protection’ LD, measurements in a ‘measurements’ LD and so forth.

The IEC 61850 standard has attempted to create LNs which represent the functions of a utility automation system. While modelling all possible functions is an almost impossible task, the vast majority of standard functions are defined and the standard permits the definition of additional LNs if they are created in accordance with the standard. An example of an LN is presented to illustrate the concept. The protection LN PTOC, protection time over current [2], is one of the simplest protection functions. Each LN contains data objects according to its function and each of these objects has attributes. As an example, an extract of the data objects is represented in Table 1.

Data objects

status information

data object name









time dial multiplier



directional mode

Table 1: Extract of PTOC LN definition

Common data classes (CDCs) [3] defines a set of common attributes which each data object can contain, further standardising the definition of data. In the example above, the ‘operate’ data object has attributes in the class protection activation information (ACT) and this would be common to the ‘Op’ data object of P logical nodes. An extract of the ACT CDC is shown in Table 2.

ACT class


data attribute name








Table 2: Extract of ACT CDC definition

Fig 1 illustrates the relationship of the data in the example.

Fig 1: Illustration of data model

Communications services

The IEC 61850 standard defines a number of communication services to allow the exchange of the standardised information between IEDs. The standard is designed to accommodate changes in communications technology and the abstract services are mapped into standard protocols. The current implementation is based on Ethernet and substation communications architectures are based on switch technology where the switches are designed specifically for the substation environment. The substation local area network (LAN) can use optical or electrical interconnections; SCADA often use CAT6 or equivalent electrical connections whereas system protection applications will tend to be implemented using multi-mode optical fibre due to its superior immunity to electrical interference.

The two services which many consider to be the core of systems compliant with the standard are manufacturing message specification (MMS) and GOOSE. MMS is a Client–Server protocol and was chosen as it is a proven implementation which suits the IEC 61850 modelling and naming approach (see Communications services). MMS is typically used for the transmission of reports containing alarm, indication and analogue measurement information and controls. The Clients are usually station-level IEDs such as the SCADA gateway and HMI, and the Servers are bay-level protection, measurement and control IEDs.

GOOSE operates as multi-cast Publisher–Subscriber and is connectionless, that is there is no direct association between publisher and subscriber unlike MMS. By mapping directly into Ethernet frames, GOOSE messages are optimised for speed and are typically used to transfer information related to protection, interlocking or automatic sequences between bay-level IEDs. GOOSE messages are a replacement for electrical information exchange by switching a voltage (typically 110 V dc in GB) on to an opto-coupled input by physical contacts.

GOOSE messages are sent instantaneously by the publishing IED when the data within the message changes state. As it is a multi-cast service, it is sent to all IEDs on the LAN. Those IEDs which are configured to subscribe to this message process it in accordance with their configuration. IEDs which are not subscribers discard the message. It should be noted that the optimisation of network designs can employ virtual LAN or multi-cast filtering techniques to ensure that GOOSE messages are not sent to IEDs which are not subscribers. As there is no association between publishers and subscribers, it is not possible for a publishing IED to know if its message was correctly received by subscribers. To improve the probability of correct message reception, the message is re-transmitted at increasing intervals as shown in Fig 2.

Fig 2: GOOSE retransmission scheme

The stable re-transmission time (T0) can be considered a ‘heartbeat’ function and permits the subscribing IED supervise the presence of the publishing IEDs. Each new instance of a GOOSE message with a change of value of one of its dataset items, results in the increment of its state number StNum. Each of the instances in the re-transmission pattern results in an increment of the message's sequence number SeqNum. The examination of these two values allows each GOOSE message to be uniquely identified.

IED configuration

The IEC 61850 standard [4] defines the substation configuration language (SCL) and is based on XML. All IED configuration files are created in SCL according to the Schema defined in the standard. The most important configuration files are:

  • ICD: IED capability description. This file is provided for each IED and is essentially a template which describes the supported data models and services. This will be imported into an engineering software tool to allow the IED to be configured.
  • CID: configured IED description. This file can be output from an engineering tool and downloaded to an IED to configure it. It will contain all parameters required for the IED to operate in its intended configuration.
  • SCD: substation configuration description. The complete configuration of a substation, including process, bay and station-level devices.

As each file is in XML format and, as it is intended that SCL can be understood, it is possible to edit these files in any commercially available XML editor. However, this technique is cumbersome and prone to error. All vendors supplying IEDs with IEC 61850 capabilities have adapted their standard configuration tools to create SCL files. These, understandably, tend to be optimised for that vendor's product and the market for third party tools is less mature than would be hoped, although the multi-vendor support in vendor tools and the availability of vendor-independent tools is improving.

To configure an IED to communicate with another, it is necessary to define the data which is to be transferred. The mechanism for this is to create a dataset containing the data items which may be attributes or entire objects, depending on the capability of the IED. An IED may have several datasets available for various purposes. For example, an IED may have a local HMI and an SCADA gateway as MMS clients and may also be a GOOSE publisher and so a minimum of three datasets could be required. Fig 3 shows a simple dataset, intended for transmission in a GOOSE message, which contains the data object (PTOC1.ST.Op) and its attributes (general, q and t) as an illustration.

Fig 3: Simple IED dataset

Another feature of IEC 61850 is that the semantics of the data are retained. So for example, the IED subscribing to the dataset shown in Fig 3 would do so with the full name of the data object or attribute including the IED name, rather than a register number or similar reference which was commonplace with historical substation protocols. This is clearly beneficial when undertaking engineering and during commissioning and fault finding.

Advantages and applications of GOOSE messages

The design of substation protection and control systems according to the IEC 61850 standard offers many advantages over conventional solutions. Many of these can be realised by the implementation of GOOSE messaging which improves existing and enables new applications, some of which would be difficult or costly to implement with a hard-wired solution.

Benefits of GOOSE messaging

GOOSE messaging offers many improvements in the implementation of existing applications when compared with hard-wired solutions and can enable new applications.

Speed of operation

The standard [2] defines message types and performance classes and GOOSE messages are typically used for Fast messages of Type 1A (‘Trip’) and Type 1B (‘Others’). Type 1A messages would be used to transmit information related to protection applications which are time critical, Type 1B messages would be typically used for interlocking or automatic switching applications which have less demanding time requirements. Each message type is further categorised depending on the application. P1 is the designation for distribution applications (system voltages up to 33 or 132 kV in GB) and P2 and P3 are designated for transmission (system voltages up to 400 kV in GB). P1 messages would typically be permitted to be slower than P2/3. The maximum operating times for messages in each class are as follows:

  • Type 1A
    • P1 – 10 ms
    • P2/3 – 3 ms
  • Type 1B
    • P1 – 100 ms
    • P2/3 – 20 ms

The implementation of these message types varies by IED vendor but typically, the IED will be capable of publishing a number of GOOSE messages and it is likely that both Type 1A and Type 1B messages will be supported. It can be seen that, in particular, Type 1A messages of class P2/3 are very fast. A hard-wired application using contacts and opto-coupled inputs would have operating times defined by the contact speed (up to 10 ms, although faster solid-state contacts are now available) and the recognition/de-bounce time of the input (typically 5–10 ms). Thus, GOOSE messages are at least as fast as their electrical predecessors.

Multi-cast features

The multi-cast nature of GOOSE messages means that for most practical applications, there is no limit on the number of IEDs which can make use of the data contained within the message. This is much more efficient than the equivalent hard-wired application where a contact and a pair of copper wires would be required for every piece of information to be transmitted by each ‘publishing’ IED for each ‘subscriber’. Applications where a number of IEDs require the information published by another, such as site-wide triggering of disturbance recording functions in response to activation of a protection function in one bay, become difficult to implement without inefficient use of the IED's output contacts.

Supervision and security

As described in Communications services, the re-transmission regime of GOOSE messages provides a way for the subscribing IED to determine if the IEDs from which it expects to receive messages are sending correctly. This supervision is an effective way of determining the health of the publishing IED and LAN connections, and can be used to trace faults. Hard-wired designs cannot achieve this type of supervision as the signals are the presence or absence of a voltage so it is not possible to determine if the voltage is present or absent intentionally or otherwise.

The GOOSE message is encoded and error checking is by means of CRC codes, typically up to 32 bits, giving a Hamming distance of 5. This results in a negligible probability of an erroneous GOOSE message being processed as correct. In hard-wired systems, there remains the risk of inadvertent activation of opto-coupled inputs. This can arise due to power frequency interference on the dc input or due to capacitive discharge currents caused by battery earth faults. These effects can be mitigated by the use of time delays on the activation of the input or by switching the positive and negative supplies of the input. This has an impact on performance by, in the former case, adding delays which may be detrimental to the operation of the scheme and in the latter case, by doubling the quantity of output contacts required on the initiating IED.

Test information

The standard includes facilities for testing functions in devices while connected and operating in their planned process. This is achieved by the use of the ‘Mod’ data object which can be set for the individual LN or for the whole LD. The test modes are:

  • On (the function behaves normally)
  • Blocked (the function is active but outputs are blocked)
  • Test (the function is active but results of the function are flagged as ‘test’)
  • Test/Blocked (the function is active but physical outputs to the process are blocked)
  • Off (the function is disabled)

The Test/Blocked state is particularly useful as it permits the function to be tested, generating all normal outputs, except the hard-wired contacts to the process, for example circuit-breaker tripping. Incoming GOOSE messages’ data contains a quality attribute which will reflect the test status of the publisher, allowing full testing of functions while avoiding inadvertent external actuations.

These functions perform similarly to test links or switches in hard-wired applications and permit these components to be omitted from installations, simplifying wiring and designs.


The complete description of an IED is contained in its configuration file. There are now many test tools on the market that will import this file, normally the CID file, and simulate the complete communications behaviour of the IED. This allows complete testing of the system, even if some IEDs are unavailable for testing, for example if they are in service. This flexibility allows increased confidence to be gained in the design as it can be undertaken in advance of the actual IEDs being available. It also allows much of the testing to be automated, reducing the testing time and hence overall cost of the project.

Message contents

The simple dataset shown in Fig 3 contains Boolean and timestamp data. However, all attribute types can be added to a GOOSE dataset. This is an extremely powerful capability, particularly when considering the use of analogue values. The ability to exchange analogue values between IEDs opens up a number of applications, one of which is described in Applications of GOOSE messaging.

It should also be noted that the semantics of the data are retained when the data is packaged in a GOOSE dataset. Assuming that IEDs are named appropriately, it is therefore possible to determine the source of the GOOSE message and the exact nature of the data by simple inspection, an improvement over predecessor protocols where a look-up table was often necessary.


Substation extensions are common as the needs of the network change. The addition of IEDs for, say, a new transformer or feeder, may require them to be configured to subscribe to existing GOOSE publishers. For this case, no changes are required to the publishers as they are simply multi-casting their data and the new IED's configuration will be arranged to subscribe to the required messages. Clearly, if existing IEDs are required to subscribe to GOOSE messages from the new IEDs, engineering work is required to update their configuration.

Wiring/time reduction

The benefits of GOOSE message application identified in the foregoing paragraphs are important in themselves however, the most compelling argument for this approach is the reduction achieved in the engineering and construction of protection and control equipment. With the current generation of IEDs, a significant proportion of the cost involved in protection and control is related to engineering and assembly effort. By producing IED configurations which are re-usable in future projects, significant time is saved across a portfolio of projects as only project-specific changes need to be made to standardised configuration. The elimination of a significant proportion of inter-device copper wiring has a saving in materials but the reduction in assembly time of cubicles and in the installation of cross-site cabling is more significant and will offset the inevitable short-term costs for an organisation adopting new approaches and new technology.

Applications of GOOSE messaging

As any type of data modelled in an IED can be transferred by GOOSE messages, it is clear that the possible applications are limited only by the capability of the hardware chosen. Two examples are presented which illustrate the benefits of the application of GOOSE messages.

Automatic tap control

The operation of transformers in parallel with on-load control of voltage ratio taps is a common arrangement in transmission and distribution networks (see Fig.  4 ). The automatic control of each transformer's tap changer requires the respective control units to have the position of the tap changer (usually an integer value), the measured voltage and the circulating current between the two transformers. Previously, proprietary signalling interfaces were used to transfer this information, generally in devices dedicated to this single function. However, the ability to transfer GOOSE messages containing the tap position and necessary analogue values (available in the ATCC – automatic tap change – LN) allows this function to be implemented in an IED designed for transformer applications and makes the extension of control to larger parallel groups possible.

Fig 4: GOOSE enabled tap-change control

Circuit-breaker fail

Circuit-breaker fail (CBF) operates by determining if fault current persists after the circuit breaker has been commanded to open. Traditional schemes operate by using dedicated contacts from each protection device to initiate the current measurement in the CBF device. This device would then trip all adjacent circuit-breakers feeding the fault, either using dedicated trip contacts for each circuit breaker or by ‘back-tripping’ using common tripping wires.

Using GOOSE messages, each protection device publishes its operation status to which the device hosting the CBF function subscribes. This reduces the number of contacts required and allows the CBF function to be allocated to an IED according to the designer's requirements. The operation of the CBF function (data object RBRF.Op) is published and is subscribed to by an IED in each bay to enact the ‘back-tripping’, saving on output contacts. In Fig 5, a simplified example showing back-tripping of feeder F4 when feeder F1's CB fails to open, the bus protection IED hosts the CBF function for each bay and the bay-level back tripping is enacted by the bay control and protection unit's PTRC (trip conditioning) LN. Note that only the relevant IEDs are shown for clarity. This also allows new bays to be configured to subscribe to all relevant CBF functions without disturbing in-service IEDs, using the test functions described in Benefits of GOOSE messaging.

Fig 5: CBF by GOOSE messaging


The widespread acceptance of SAS implementing the IEC61850 standard has highlighted the benefits of replacing hard-wiring with GOOSE messaging. It has been necessary to demonstrate that such systems are at least as dependable and secure as their predecessors and service experience to date has been very positive. As the systems are rolled out in significant numbers, utilities are deriving tangible time and cost savings when compared to conventional substation protection and control designs. The adoption of IEC 61850 SAS depends on a clear vision for the functions and their implementation, coupled with a robust engineering approach and a detailed understanding of the how hardware and software products implement the standards. GOOSE messaging is only one part of the standard but has the potential to provide significant benefits and enable new applications.


  1. IEC 60050: ‘ International electrotechnical vocabulary, item 605-02-09 ’.
  2. IEC 61850-5: ‘ Communication requirements for functions and device models ’.
  3. IEC 61850-7-3: ‘ Basic communication structure – common data classes ’.
  4. IEC 61850-6: ‘ Configuration description language for communication in electrical substations related to IEDs ’.

Case study

Since the early 1990s, the capability of the interconnection between the Scottish and England and Wales transmission systems has been enhanced in response to the changing nature of the system and generation patterns. Voltage uprating and reconductoring of overhead line circuits, commissioning of shunt and series reactive compensation will increase this to 4400 MW in 2016 and commissioning of the Western HVDC link in 2017 will take the capability to 6550 MW.

A System Integrity Protection (SIP) scheme was installed in 2008 to provide incremental capability of the Anglo-Scottish boundary in operational timescales by shedding generation in Scotland in response to faults on the cross-boundary circuits. Taking the performance of this scheme as a reference, it was identified that further system operational benefits could be achieved by

  • Rapid post-fault switch in of shunt capacitive compensation, improving voltage stability. (The reference for this scheme is ASACS, Anglo-Scottish Auto Close Scheme.)
  • Instructing an increase of the Western HVDC Link's North to South power transfer setpoint in response to AC system faults, improving transient stability. (The reference for this scheme is FRS, Fast Ramping Scheme.).
  • Automatically bypassing Series Capacitors under certain system conditions, further reducing the risk of a Sub-Synchronous Oscillation event. (The reference for this scheme is Series Compensation Management Scheme (SCMS).

Building on the experience of the original SIP scheme (referred to as Operational Tripping Scheme, OTS), an integrated solution was proposed to provide the System Operator with a diverse selection of tools to enhance the capability of the transmission system in real-time by enhancing pre-fault transfer capability and providing economic benefit by reducing the costs associated with constraining generation. Such a scheme became possible through the application of IEC 61850 GOOSE services.

Definition of scheme requirements

The high-level functional requirements were defined as

  • The four scheme elements (OTS, ASACS, FRS, SCMS) must be independent; the status or availability of one scheme must not affect the others.
  • The design of the integrated scheme must allow the schemes to be extended and the operating logic to be modified while minimising the downtime of the scheme.
  • The performance requirements of each scheme must be satisfied and not be influenced by the operation of the others.
  • The scheme must be dual redundant, employing diverse hardware, communications routes and power supplies such that no single failure would cause any of the four scheme elements to be inoperative.
  • The scheme must be operated and maintained as part of business-as-usual processes.

The basic operation of each of the four scheme elements is to determine network connectivity, identifying conditions which have been determined to require action. This consists of 28 circuit ends at 13 sites. A simplified block diagram is shown in Fig 6.

Fig 6: Simplified network schematic

To extract the maximum benefit from each scheme element, the following scheme operating times were defined:

  • OTS: from fault inception to issuing a command to any of the eleven generators available shall be <80 ms (as per the existing scheme).
  • ASACS: from fault inception to issuing a command to close any of the eleven shunt capacitors’ circuit breakers shall be <80 ms.
  • FRS: from fault inception to issuing a ramp command to the HVDC control system shall be <80 ms.
  • SCMS: from fault inception to issuing a bypass action to the series compensation control system shall be <80 ms.

From the performance and high-level design requirements, it was determined that the system connectivity monitoring was identical or very similar for each scheme element and that it was an application that would be best delivered making use of GOOSE messages.

Existing OTS

The existing OTS gathers circuit status from remote sites using protection IEDs with communications channels supporting multiple binary status points and transmits these to a central controller as shown in Fig 7 (only one of the redundant systems is shown). The circuit status inputs consist of double point indications of each plant item and associated protection, hard wired to the IEDs. (Protection operation is used to enhance the speed of operation of the scheme by anticipating the opening of the circuit breaker and avoiding its opening time.) The determination of circuit status is performed at the remote site IED and sent to a receiving IED via external communications to the remote site using services according to the IEC 62843 (IEEE C37.94) standard. The controllers, and the IEDs receiving the circuit status, are located at a central substation which acts a hub for the schemes. The circuit status information is transmitted to the controllers by IEC 61850 GOOSE services.

Fig 7: Simplified OTS representation

This concept has been proven in service since 2008 and was considered to be suitable for retention and to be replicated for the three additional scheme elements.

Scheme architecture

The detection of circuit status is common to all four scheme elements and many of the circuits monitored are used in more than one scheme element. The creation of a common layer of circuit status information would allow the status of any monitored point to be available to the scheme elements which required it. Following a historic naming convention, this fifth scheme element is known as the Line End Open (LEO) Collection Scheme. In common with the other scheme elements, the LEO scheme is fully duplicated.

The existence of the LEO scheme publishing circuit status information in GOOSE datasets permits the four scheme elements to be added as required. Each element's scheme controller is configured to subscribe to the relevant status points, creating independent scheme elements as required.

Each scheme element (OTS, ASACS, FRS, SCMS) has, in addition to its Scheme Controller, IEDs to perform the required functions:

  • OTS send IEDs to seven remote generator sites.
  • ASACS send IEDs to six remote sites with shunt reactive compensation.
  • SCMS send IEDs to three remote sites with series compensation.
  • FRS send IED to the remote HVDC converter station.

GOOSE and network configuration

The Ethernet arrangement at the hub substation consists of two redundant systems as shown in Fig 8 (only one system shown for clarity). Each scheme element has a star configuration and is assigned an Ethernet switch, each of which are connected in a ring configuration using RSTP. All connections are optical. This arrangement facilitates the redundancy requirements and is additionally resilient to the loss of one link between switches in the ring.

Fig 8: Simplified network arrangement

The receiving IEDs in the LEO scheme map the status points delivered at the external communications interface to a GOOSE dataset. The Scheme Controllers are configured to subscribe to the relevant LEO points which are then manipulated in the IED's configurable logic according to the defined operating requirements of the scheme element. Outputs from the controllers are mapped into a GOOSE data set and the associated scheme IEDs are configured to subscribe to this and send the required command via C37.94 communications channels to the remote site for action. This is illustrated in Fig 9.

Fig 9: Simplified information flow

Testing and commissioning

As the schemes were built on the existing OTS, it was vital that the down time of the OTS was minimised while the new elements were added. Using spare hardware, the new configurations were tested in a factory environment.

The new scheme elements required additional sites to be added to the LEO scheme and these were assembled in the factory, along with the IEDs for the ASACS, SCMS and FRS, including remote ends. This allowed the majority of the scheme to be tested using the project hardware prior to being dispatched to site. During the factory tests, vendor and third party IEC 61850 tools were used to monitor GOOSE on the network.

The existing LEO IEDs were not available for testing in the factory; previously, when IEDs were not available for testing, other IEDs in the factory would have been loaded with temporary configurations to simulate them. However, this is not a satisfactory arrangement from the perspective of version and quality control and can lead to errors. The approach taken in this scheme was to use third party software tools to simulate the missing IEDs. A CID file was generated from the IED configuration software and imported into the IEC 61850 simulator software. The simulator was then used to generate GOOSE and complete the testing of the scheme. The correct operation of the simulator was verified by first using a CID file from an IED available in the factory and comparing it with the operation of the physical IED.

At the scheme hub, there was no electrical wiring to complete, other than power supplies and earthing, reducing the installation time significantly when compared with previous schemes.

As there had been extensive factory testing, when the hardware was installed, there was a high degree of confidence in the readiness for service. This reduced the content of the site tests to verification of external connections (at the remote sites) and to interfaces with the existing OTS. The downtime of the existing OTS was minimised as a result.

The OTS and ASACS were put into service in the first phase. The SCMS was fully commissioned a few months later, without removing OTS or ASACS from service, confirming that the requirement for complete independence of each of the scheme elements had been satisfied.

Benefits of the scheme

The fast pace of change of transmission networks in response to changing generation and demand patterns requires that SIP schemes can be modified, extended and upgraded quickly and with confidence. The early application of the approach outlined, the original OTS, demonstrated these features but did not foresee the additional levels of functionality which were required. However, now that this architecture is in place, the addition of any new SIP function is simple. The use of simulation tools will allow new elements to be added, or existing to be reconfigured with no down time of any other part of the scheme. The relatively low cost of these schemes contrasts with the additional system constraint costs incurred in their absence.

The need for flexibility was illustrated during the delivery of the project when a request was received from the system operator to add generators to the OTS in response to changes to the generation background in Scotland. As the OTS Scheme controller had been configured to publish a GOOSE dataset containing the required scheme status information, the new OTS IEDs were configured, tested in the factory using a simulator populated by the Scheme Controller's CID file and commissioned with no outage of the OTS scheme. This is a significant benefit for schemes of this type.

In addition to the flexibility and testing benefits outlined, GOOSE is demonstrably faster than the combination of electrical contact and opto-coupled input. A traditional electrical contact would have an operating time of around 5 ms and, in order to improve immunity to capacitive discharge currents, opto-coupled inputs are set with a buffer time of 5–10 ms. This would have a significant impact on the overall scheme operating times.

Table 3 illustrates that delivering status information by GOOSE, coupled with reliable high-speed inter-station communications, results in very low operating times which maximises the effectiveness of the schemes.


Time, ms

fault inception


protection operation and LEO send to Hub


LEO Receive-GOOSE to Controller-GOOSE to ASACS send


ASACS receive and CB close command


Table 3: Typical scheme timing

It is arguably more secure to deliver status information by GOOSE as (in an all optical network) there is no risk of electrical interference causing incorrect pick up of an input. It is also more dependable as GOOSE reception can be supervised by creating a SCADA event should the publishing IED fail.

Lessons learned

The experience gained in the development and deployment of systems based on IEC 61850 GOOSE services from the late 2000s has enabled hard-wired schemes to be decommissioned and they are no longer considered for complex schemes related to the transmission system.

The use of GOOSE has enabled a multi-level System Integrity Protection Scheme to be rapidly developed and deployed. It has been proven that with careful design, the diverse scheme elements can co-exist on a station LAN but can be considered independent. This has facilitated a staged installation and commissioning process, as required by transmission system considerations. It has allowed scheme changes and extensions to be executed with minimum down time of the affected scheme element and with no impact on other scheme elements.


Go to the profile of Craig McTaggart

Craig McTaggart

Transmission network manager , Scottish Power

No comments yet.