Power Plant Upgradation: Advances in control systems for TPPs

Advances in control systems for TPPs

Arghya Roy, Chief Manager, Digital Transformation, India Power Corporation Limited

Traditionally, there have been four broad types of electric power generation in India: thermal, hydro, renewable and nuclear. Of these, India continues to rely heavily on thermal power. As of June 2018, out of the total 344 GW of installed capacity in the country, 57 per cent comes from thermal units, which use coal as fuel. While the intention of the Central Electricity Authority (CEA) is to reduce the dependence on fossil fuel to below 50 per cent by 2022, thermal power generation will remain a major contributor of power in the days to come.

In recent times, we have witnessed an impressive growth in the usage of advanced technology in power plants. In any thermal power plant, the three key elements that need to be continuously monitored are the boiler, turbine and generator. Since these three units are continuously in operation, it is of utmost importance to minimise the human intervention while operating them. Traditionally, proportional–integral–derivative (PID) controllers, along with pneumatics, are used to control the boiler operation and in many thermal power plants, they are still in use. Conventional controllers do not work accurately in power plants due to uncertainty and load disturbances. And due to this, technologies based on programmable logic controls (PLCs) and distributed control systems (DCS) have quickly become popular and forayed into the control system of a thermal power plant. These DCSs/PLCs typically have a human-machine interface (HMI) or a graphical level interface through which a plant engineer can control the boiler, turbine and generator of a unit within the plant. In fact, it is possible to connect unit DCSs/PLCs to each other via a common protocol like Modbus so that a plant-level continuous monitoring system is established.

Quite often, at least at the plant level, the terms “DCS” and “PLC” are used interchangeably. This is a misnomer and, therefore, it is important to distinguish between a DCS and PLC properly. A PLC is more like a computer with all the hardware and software to do a specific automation task. It accepts inputs via “sensors”, then executes certain “logic” operation and finally instructs “actuators/controllers” to perform a task. Assuming there are 100 parameters that are being monitored and controlled in a single boiler, then a PLC can be deployed for, say, 40 parameters. PLCs can take “analogue” inputs and convert the same to “binary” and then transmit the output in binary.

A DCS, on the other hand, can be thought of as a large-scale combination of multiple PLCs or custom controllers, grouped together for performing similar tasks. They are quite suitable for a large-scale, continuous process and necessarily have “in-built redundancy”, ensuring a higher level of system insurance. Besides, a DCS offers considerable flexibilities when it comes to maintenance and operation over a PLC. Just to give an idea, inside a DCS, one can modify/update/add new logic even if it is operational. This is not possible in PLCs.

In view of the above, these days most of the plants are being “upgraded” to have DCS systems only. Traditionally, DCSs were more expensive than PLCs.

However, these days the cost of DCS systems has reduced drastically and the difference in cost between a PLC and a DCS is diminishing. However, the “upgrade” brings some challenges. In a typical thermal power plant, some PLCs are manufactured by various vendors. If a centralised DCS is to be implemented, the question is, how can these PLCs would “talk” to a DCS? Even within the same vendor make, some PLCs are outdated and, therefore, cannot be integrated with a modern DCS. Usually, each device, be it a PLC or a DCS, “talks” to the other via a standard “protocol” like Fieldbus, Modbus and Ethernet (transmission control protocol [TCP/IP]). And there are software that are implementing these protocols to make communication (or talk) possible among devices. Old or Outdated PLCs (even in some cases, DCSs) are not compliant with modern protocol and, therefore, remained isolated.

We are often used to see that in a plant, it is a mix of PLCs and DCSs of different manufacturers and of different versions. So it becomes practically impossible to integrate them.

Secondly, when a plant is upgraded to have a DCS for multiple units, the related HMI is also upgraded/changed. Since HMI needs to be compatible with the existing computer RAM and Windows Server edition, it is an important parameter (cost of procuring licences) to consider when upgradation work is taken up.

Third, and most important, even if a plant has an established communication protocol, how can PLCs and/or custom controllers communicate with each other? Just to give an idea, the ABB Procontrol 13 (or P13) DCS can be Modbus/TCP protocol compliant, but it still cannot communicate with the BHEL Max DNA (another Modbus compliant system). Why? Because there is no communication “framework” (or software) that lies in between. Usually, in this case, an OPC (OLE for Process Control) framework comes as an aid. OPC helps to access PLC variables using the COM/ DCOM (Component Object Model/Distributed Component Object Model) framework. It will capture PLC variables as an OPC object so that you could present it visually, using HMI supervisory control and data acquisition (SCADA) software or any other programming language since OPC is open standard. In order to capture data from a PLC, OPC as a computer application will have to use communication protocols, like Modbus, TCP/IP.

The architecture in the optimal figure depicts a typical client-server model. All machine unit is connected to at the OPC server (master) through a standard protocol (here it is Modbus). OPC clients (slaves) are nothing but different applications for different needs. OPC CMS is used as the centralised monitoring system. OPC Report is for taking out reports. For this module, OPC DA (OPC data access), coupled with a Historian Application, can be used. We can even quickly add another OPC client for SCADA LabView to control the PLCs.

To summarise, OPC is a framework that implements and uses standard protocols like Modbus, and TCP/IP to allow users to control each of the devices via PLCs/DCSs.

Often people think that SCADA is a better substitute for DCS. This is not true. DCS is still a better choice where reliability and fault tolerance are concerned. DCS is also a better option for installation within the plant. It is to be noted that the lifespan of the present-day sensors, actuators or other field devices is notoriously low (less than two to three years). Therefore, replacing those devices without impacting the DCS functionalities is of prime importance for a maintenance manager. DCS can collate multiple PLCs along with field devices, while SCADA can do the same only with PLCs.

In order to build and deploy a full-fledged monitoring and control system for multiple power plants, a combination of SCADA and DCSs can be thought of as a first-line solution.

Plant upgradation or installing a new control application requires an in-depth understanding of the existing system. As mentioned above, the cost of replacing the existing communication links involves huge capital expenses. In addition, the cost of software licences is significant. Therefore, a judicious mix of hardware and software needs to be chosen. It is always better to bring in a consulting firm to get the most optimised solution.