Use of Virtual Intelligent Electronic Devices for substation protection and control

	David Macdonald		David Madrid		Marcus Stollfuss

Introduction

 

The power system protection industry is currently facing a number of challenges. A large percentage of the installed base of Intelligent Electronic Devices (IEDs) are at the end of their useful life or approaching it. Replacement projects are cumbersome in terms of the engineering and testing required, and both greenfield and brownfield projects require the installation of many devices.

 

The grid is changing, and naturally new automation and protection requirements are arising, but it is not quite so easy to add new functionalities to an already installed Protection, Automation and Control Systems (PACS) without having to visit the substation itself.  In the case that an IED fails, it should have a like-for-like corrective replacement. This requires a plethora of spare parts for each manufacturer and model, which often have to be stored centrally. Consequently, corrective maintenance tasks need to be performed on site and often include much time spent travelling to the substation. 

 

Centralized and Virtualized Protection and Control Systems

 

Against the backdrop of these challenges some solutions are made possible by the emergence of rugged, multicore high performance computing platforms and the IEC 61850-9-2 process bus. Combined, these technologies enable housing many protection applications within one device, and for this device to subscribe to current and voltage measurements for several bays without the need for extensive and error prone cabling of inputs and outputs.  This consolidation of cabling makes it feasible to centralize all Protection and Control Functionalities into a single redundant device. When this centralization is applied with Functionality fixed to Hardware it is called a  “Centralized Protection and Control (CPC) system. It offers not just savings in device costs, but also faster installation and synergies in testing. However, some disadvantages persist:

 

• the applications cannot easily be managed independently,
• new applications or bay extensions cannot easily be implemented,
• it is not possible for the end user to specify the hardware platform to be used,
• the functionality is still fixed to hardware. The end of the hardware lifecycle is thus also the end of the software lifecycle.

 

While CPC centralizes functions on dedicated hardware, Virtualized Protection and Control (VPAC) represents an evolution that decouples software from hardware, offering greater flexibility and scalability. A VPAC System is one in which the software is not fixed to the hardware but is rather independent of specific hardware. VPAC systems can have the same consolidation of devices as CPC systems, but they also have an independence of the software applications not only from the hardware but also from each other. This separation between software and hardware makes it possible to centralize many, if not all, protection and control applications in a scalable way within one system. It also brings new possibilities for software deployment, interoperability, updating, maintenance, replacement and testing. Consequently, centralized protection is of monolithic character and can make the upgrade of individual protection functions difficult; virtualization features a level of application isolation allowing different parts of the system to be updated and managed separately from each other. For example, in a scenario where a protection function needs to be updated, VPAC enables remote deployment without physical intervention at the substation, significantly reducing time and maintenance costs.

 

This level of application isolation grants VPAC systems another important advantage over centralized PACS: interoperability. This interoperability is crucial for utilities seeking to reduce dependency on a single vendor and to integrate applications from different manufacturers within the same hardware.

 

VPAC systems offer not just a compelling business case for end users, but also a whole set of functional benefits including:

 

• The flexibility to add new functionalities to the substation automation system without having to add new hardware.
• The ability to upgrade not just the protection or control firmware but the complete application during the lifecycle of the hardware.
• The opportunity to remotely test new applications (empowering VPAC systems to become springboards of innovation), when end users can apply IP connectivity to their VPAC systems.
• The reduced number of device types that need to be kept as spares for corrective maintenance due to vast hardware agnosticism. This means that spares can be distributed throughout the utility territory and corrective maintenance can be managed by localized substation staff.
• Straightforward replacement projects. If the application requirements remain the same, no change may be required to the configuration. This could significantly reduce the engineering and testing effort in replacement projects.

 

Features and Challenges of Virtualized Control Systems

 

VPAC technology has of course its own set of challenges, and CIGRE WG B5.84 is developing recommendations for the end user to help understand, specify, deploy and maintain this technology.

 

Figure 1 Diagram showing both Container based and Virtual Machine based Virtualisation

 

The diagram in figure 1 illustrates the two principal methods of virtualization, with the left-hand side showing a VPAC system with a hypervisor and virtual machines and the right-hand side showing various containers running directly on a container engine. The difference between them is that the virtual machine contains its own Operating System (OS) whereas containers all run on the host operating system. This makes containers lightweight but without as much application isolation as the virtual machine.

 

Both the Virtual Machine and the container combined with its operating system have all that they need to run their application: the tools, libraries, application code and the runtime code. The figure shows the physical Network Interface Card (NIC) in both servers which connect the VPAC system with the local area networks. The NICs are connected to virtualized networking components such as the linux bridge or the virtual switch where packets are forwarded onto the individual applications, be they virtual machines or containers. Hybrid architectures, where the containerized application resides within the virtual machine, are sometimes used to give the benefits of application isolation from the virtual machine with its own OS, and the scalability of using containers. The technical brochure of B5.84 will give more details on this in the chapter on the virtual IED.

 

One of the challenges of virtualisation is to guarantee low latency and deterministic performance. The communication architecture can be designed to accelerate the transmission and processing of the network packets. For example, this can be done by using Peripheral Component Interconnect (PCI) passthrough, as shown in Figure 2, which allows for bypassing host and linking virtual machines directly to a network interface card in such a manner that the virtual machine can access the Network Interface Card (NIC) directly by communication with the NIC as if the virtual machine were the host.