The modern DCS: A fifth wheel?
One of the more intriguing discoveries of the research (and one that calls for further investigation) is the relationship between the plant DCS and all of these separate applications. If you visit the web sites of the major power plant DCS providers, you’ll realize that most of their systems duplicate (or at least attempt to duplicate) the capabilities and functionality of the diverse software packages available from non-DCS vendors.
To understand the importance of this issue, consider the software complement in a desktop PC. It comes loaded with a suite of applications from many suppliers. But the vast majority of users only employ a small fraction of the suite’s capabilities. One reason for that is redundant functionality. As one interviewee recognized, “Although Microsoft includes anti-virus software in its suite, most everyone still uses Norton for protection.”
Another respondent shed light on the compatibility consequences of using multiple applications. He reported that although the DCS recently retrofit to one of his plant’s units includes a data historian, the DCS still was configured to communicate with the historian used by other plants of the fleet, for consistency’s sake. Similarly, a DCS may include a work management (WM) application, but it still must interface to the legacy WM package that other plants use. The need to remain backward-compatible with existing applications is a big reason why software supplied with a DCS often isn’t used to its full extent.
A decade ago, it was generally assumed, for good reason, that most if not all of the functionality of emerging applications would become embedded in DCS offerings. The DCS could then serve as a plant’s common knowledge management “platform.” Today, however, data from the DCS still are exported through standard communication protocols, usually via the plant historian. In most cases, all “layered” software functions for managing data and information and sharing them throughout the organization are fed by the historian.
These integration and compatibility issues spawn a variety of interesting considerations and questions that deserve to be addressed and answered:
- Surely part of the reason why software applications have become layered has been distributed control systems’ fitful migration away from proprietary designs and toward open architectures. Indeed, almost all modern software packages are developed for open, PC-based environments.
- At most plants, the existing data historian enjoys a “first-mover advantage.” Fleet owners have standardized on one system and made it the interface between the DCS and other software applications, and plant systems and the corporate mainframe. One user described this link as the plant’s “communications conduit.”
- Most recent DCS deployments have included the installation of functionality that may already exist, increasing final project costs unnecessarily. Much of the redundant functionality comes from applications layered outside the DCS.
- Is there unused capability in a plant’s existing system that could be exploited? One respondent said yes, vaguely quantifying it as “massive.” This is another piece of evidence to support the validity of the desktop PC analogy.
- One fleet center manager reported that his company has spent $200 million to upgrade the distributed control systems of its centrally monitored plants. But he also said that another $10 million has been spent on software applications layered around them for the remote diagnostics centers.
The last point raises some philosophical questions. DCS retrofits often include the installation of lots of new hardware, such as sensors and transmitters. After subtracting their costs from the project budget, a large cost, and therefore value disparity, remains between the DCS and external software functionality. How should these two values be apportioned? In other industries, knowledge about an asset has increased in value relative to the value of the asset itself. Will that be the case for power plants?
During the research interviews, one fleet manager spoke at length of the “unintended consequences” of moving to a PC platform. One is that PCs don’t work very well in real-time environments. Another is that, despite automatic updates, it’s still extremely time-consuming to download all the security patches needed to protect PCs from new and more-pernicious viruses and cyber-intrusion schemes that hackers cook up worldwide on a daily basis.
Another unintended consequence of the move to open, PC-based architectures is being felt in remote alarm management and monitoring. One fleet manager reported that 35% to 40% of the alarms sounded at his plants are “system” alarms—malfunctions of the control system, rather than of plant equipment. Lately, there have been more alarms of greater diversity, he added.
Based entirely on the research results, the value of integrated knowledge management has plenty of opportunities for growth. It will be interesting to see whether power plants being planned and built today will consider their knowledge management system—comprising the DCS and all of the functional software needed to economically optimize plant operations and performance—an “island” in the way that plants a decade ago considered their boilers and turbines islands for contractual purposes. At a practical level, will new plant owners make one contractor responsible for integrating all of the software functionality within their plant into a logical and optimized whole?
Email
Comments
Print
Reuse
