Honeywell Avoids DCS Obsolescence Pitfalls

Author photo: Harry Forbes
ByHarry Forbes
Category:
ARCView

Summary

The worldwide installed base of distributed control systems (DCS) includes a remarkably large number of systems that are quite old. Many of these systems date from the 1990s or even the late 1980s, the first or second decade in which DCS existed. The situation is not limited to a single supplier. Indeed, several suppliers have significant portions of their installed base running production process units with very old DCS Obsolescence Honeywell%20DCS%201.JPGequipment.  This represents a problem for process industry end users and DCS suppliers alike.

For end users, the problem is system obsolescence, potentially causing loss of production because replacement parts are unavailable. For suppliers, the difficulty of supporting older equipment grows as their technical support organizations lose expertise in old products, replacement parts become difficult or impossible to source, and old technologies (both hardware and software) become obsolete. This situation threatens a DCS supplier’s long-term customer relationships.

In this report, ARC will look at how this situation evolved, why it represents a major difficulty for DCS end users, and look at the case of how one supplier (Honeywell) has developed simplified upgrade paths for its earliest DCS products.

Origins of the DCS Obsolescence Issue

Distributed control systems were first introduced in the mid-1970s.  At the time, the DCS represented the application of microprocessor technology and a digital intrusion into what had been an entirely analog world of continuous process control. At the time, there was no concept of a local area network (LAN). The concept of computer networking in general was primitive and highly proprietary.  DCS was introduced in the years before General Motors began its MAP/TOP initiative and before the network standardization efforts of the early 1980s (1979-1983), which resulted in the three IEEE 802 standards for LANs (Ethernet, token bus, and token ring).

At the time, the network technology stack for a DCS had to be developed entirely by the supplier.  In this early era, DCS suppliers were highly uncertain about not only the future of the technology they were using, but also of the DCS lifecycle.  Given this massive amount of uncertainty and difficulty in product development, the evolution of multiple DCS products in this early era is remarkable.

Perilous Situation of DCS End Users

End users adopted early DCS in pursuit of solid operational benefits. At the time, they were operating process units with analog control systems that were difficult to document and to keep “in tune” for adequate performance. The performance of controllers and other dynamic elements in the system was determined by the physical settings of various potentiometers on individual modules. These potentiometers were easily adjustable (perhaps too easily!) and a faulty adjustment could cause problems not only in the module or control loops that were adjusted, but also in other loops in the unit that were coupled with the poorly performing loop. This and many other factors made it very difficult to analyze the root cause of control problems. Thus, keeping an analog control system in tune and optimizing its performance was an extremely DCS Obsolescence Honeywell%20DCS%202.JPGdifficult though high-value task.

The development of the DCS brought the repeatability and accuracy of digital processing to the process control discipline. The dynamic parameters and scaling of DCS modules and function blocks were stored digitally and could be well documented.  This enabled the overall control system performance to be much more repeatable and consistently maintained. End users could thus develop more comprehensive and complex control system designs, which would improve process performance while delivering highly reliable process control. The distributed nature of the control function in a DCS helped enable this reliability.

While the human-machine interfaces (HMIs) of the early DCSs were certainly not better than the panel boards they replaced, end users were willing to trade off a less-than-optimal HMI to obtain a higher-performing control system and for the improved plant performance from using a digital system.

What the early DCS end users did not realize is that the upgrade path for their new DCS would be difficult, disruptive, and expensive.  Oftentimes, it was difficult for end users to identify specific business value that could be achieved by upgrading their DCS from one version to the next. The initial transition from analog to digital clearly delivered value, but the transition from one digital generation to the next did not promise similar increases in business value, especially for upgrades to the process controllers and sensor I/O equipment. As a result, many end-users simply decided to delay upgrades to their controls and I/O for as long as possible.  In the long run, this created a situation in which end users were running obsolete equipment to control their processes and suppliers were struggling to support the same obsolete equipment in their installed base.  DCS suppliers had developed better migration solutions for DCS I/O and control, but the disruption, cost and risk of installing revised systems deterred end users from taking action to replace them.

The Case of Honeywell

With the introduction of the TDC2000 product line in 1975, Honeywell was the first firm to introduce a DCS.  The company enjoyed great success in the early DCS market and thousands of TDC2000 nodes were deployed by Honeywell customers. TDC2000 was introduced before there were any networking standards, so the system employed a proprietary “Data Hiway” network that linked the various stations.  The next generation DCS Obsolescence Honeywell%20TDC3000%20DCS%20Configuration.JPGof Honeywell DCS (TDC3000) employed the same proprietary network. 

As networking standards developed, Honeywell built the networks for later DCS products based on the IEEE 802.4 token bus, which was the basis of the Honeywell LCN (Local Control Network) and later on the IEEE 802.3 (Ethernet) standard, which underlies the Honeywell FTE (Fault Tolerant Ethernet) network. During this evolution, Honeywell integrated the Data Hiway and LCN networks using gateway products.

Honeywell’s early success in DCS, however, combined with the end user reticence about upgrading DCS control and I/O, left Honeywell with a large installed base of TDC2000 and TDC3000 systems.  Eventually, most of the installed base moved to TDC3000 and even today there are thousands of nodes of TDC3000 systems running important processes for many Honeywell customers. After 45 years of life, many hardware components (especially microprocessors) are increasingly difficult to find.  Large Honeywell customers appeared to be facing a crisis in that their manufacturing operations were controlled by hundreds of systems that could not be replaced except by disruptive “rip-and-replace" projects that each required extensive re-engineering of legacy control applications.

DCS Obsolescence Honeywell%20Appliance%20for%20LCN%20Migration.JPGHoneywell developed a multi-faceted strategy to deal with this situation. The first aspect of the program was to migrate the control and I/O modules (called HPMs) from the TDC3000 to the present Honeywell Experion automation product line. The high modularity of the HPM product enabled Honeywell to create plug-compatible upgrades for both the controller and the new Ethernet-based networks used in the Experion product. Revisions to the legacy I/O modules also incorporated the same technology, so both control and I/O within the HPM could be easily migrated to the new Experion system with the production process in operation and while preserving the customer’s control configurations.

While this was a substantial step forward, it was only a partial solution, since the installed base still had many legacy TDC3000 stations running on the older proprietary networks from the 1980s. These stations - which ran specialized end user applications, historical data collection, and other important functions - also required an evolution.

Honeywell’s solution for migrating the remainder of the system is called the “Experion LCN (ELCN).” ELCN preserves decades of customer control applications, graphics, and procedures in their entirety while giving end users the continuous innovation capabilities of a new Experion system.  Honeywell also developed an “on process” migration capability that allows the evolution to be performed as a simple upgrade – no different than the many years of software updates provided over the past decades. Doing so avoids the need for any interruption to process operations. Honeywell effectively virtualized the legacy functions and gave them an indefinite life, while also providing integration with the company’s newest DCS products.

Impact on Honeywell End Users

The ELCN program has greatly improved the situation for process plants still running TDC3000 systems. Before the EHPM and ELCN, these users faced the prospect of having  to re-engineer all their controls, DCS Obsolescence Proprietary%20DCS%20Stations%20Replaced.JPGgraphics, and procedures on a new system, a substantial and high-risk project. Given that customers still had thousands of legacy nodes running critical production units, hardware obsolescence represented a significant threat to their future production. Rip-and-replace upgrade programs for these legacy systems would take many years to execute because each replacement project would require re-engineering of legacy functionality. Migration to the new ELCN eliminates the hardware obsolescence problem and provides access to all the new capabilities of the Experion system. The customer migration to ELCN removes the need to inventory legacy parts since their functionality is performed in either physical or virtual machines that employ today’s standardized compute platforms. The ELCN has taken the time pressure off end users who still run TDC3000 nodes.

Impact on Future Open Automation

It is well known that the genesis of the Open Process Automation Forum (a forum of The Open Group) occurred because a major end-user (ExxonMobil) faced exactly this hardware obsolescence situation on a very large scale. Given that ExxonMobil faced this obsolescence in hundreds of process units, the development of the ELCN and the emulation/virtualization combination it represents has alleviated that company’s imminent hardware obsolescence crisis. This has led some industry observers to question whether there remains a need for the OPAF and its standardization initiative. While ExxonMobil has restated its commitment to the OPAF, it is a valid question that if hardware obsolescence will not drive adoption of future open process automation systems, then what will? In ARC Advisory Group’s view, widespread acceptance of open process automation systems will require that they deliver new features and applications beyond those available in today’s DCS products. This would be like what drove the initial adoption of DCS in the 1970s and 1980s.

Open process automation systems might ride on the coattails of open source software. Examples of such new types of applications and features might be enterprise-wide visibility of process control and device state.  Potentially, this could be derived from the use of common APIs and open source software in future open process automation systems. ARC believes that a like-for-like replacement of an existing DCS with an open process automation system is not a great value proposition unless and until significant new business value is delivered by adoption of the new architecture.

Recommendations

  • End users of legacy DCS should learn their supplier migration road maps and discuss emulation and virtualization options with their incumbent DCS suppliers. Make sure you understand all options for migrating legacy systems to current DCS product lines.
  • Advocates of open process automation must focus on value that current DCS has great difficulty delivering, such as standards-based application interface and enterprise-wide operations visibility and management. It is unrealistic to expect open process automation systems to capture a large segment of the DCS market without delivering new types of business value not achievable with existing DCS products.
  • DCS suppliers should carefully evaluate emulation and virtualization technologies and solutions to simplify migration of their legacy installed base products to current state-of-the-art systems.

Experion is a registered trademark of Honeywell International Inc.  All other trademarks mentioned are the property of their respective owners.

 

ARC Advisory Group Clients can view the complete report at ARC Client Portal.

If you would like to buy this report or obtain information about how to become a client, please Contact Us     

 

Keywords: DCS, ELCN, Experion LCN, Honeywell, LCN, Obsolescence, TDC3000, Virtualization, ARC Advisory Group.

 

 

Engage with ARC Advisory Group

Representative End User Clients
Representative Automation Clients
Representative Software Clients