Batch Cycle Time Reduction Project Recovers Chemical Manufacturer’s Lost Productivity After a DCS Migration From PROVOX™ to DeltaV™
07.6.2022Case study by Alan Polk, Technical Innovation Leader at Hargrove Controls + Automation
Legacy control systems are a major concern for manufacturers across the U.S. as well as globally. Obsolescence makes it hard if not impossible to find replacement parts or support and migrating is a necessity to avoid inevitable costly downtime. However, every industrial control system (ICS) platform has its own set of nuances and best practices when it comes to communication protocols, programming, troubleshooting, networking, etc. Migration is not straightforward but maintaining or gaining productivity should be expected. Unfortunately, that is not always the case.
Project Summary
Hargrove Controls + Automation Team recently completed a project to help a chemical manufacturer recover productivity losses caused by an unexpected increase in cycle time after another integrator had migrated the plant’s legacy Emerson PROVOX™ to a DeltaV™ distributed control system (DCS). The lost productivity was costing the end user more than one million dollars per month. During the project, a potentially dangerous safety hazard associated with the original migration was also identified and mitigated. The project’s return on investment for the end user was less than one year.
Problem
The third-party migration from legacy Emerson PROVOX™ to DeltaV™ distributed control system (DCS) increased the cycle time on a train of eight chemical reactors by approximately 6%, costing the end user more than one million dollars per month in lost productivity. Hargrove Controls + Automation engineers were tasked with investigating where time was being lost in the batch process due to logic changes during migration. The goal was to recover as much time as possible to increase productivity.
Discovery Phase
A review of the new logic was undertaken, and it was discovered that the logic was migrated in a manner that kept the original phase structure intact from PROVOX™ into DeltaV™. Unfortunately, key differences in PROVOX™ and DeltaV™ system architecture on how phases are loaded and executed was causing long pauses in the new DeltaV™ batch process.
The pauses occurred where devices in the unit were idle while waiting for DeltaV™ to unload the current phase and load the next phase. This issue was exacerbated by the fact that the new DeltaV™ controllers were operating beyond the ideal loading capacity, so unloading and loading phases were taking longer than they normally would. A lack of available controller processing capacity prevented the phases from being permanently loaded into memory or being allowed to execute at a faster scan rate.
The Ideal Solution
An ideal solution would have been to rebuild all the batch logic taking into account key differences in how phases are loaded into DeltaV™. This would set up the logic in such a manner that DeltaV™ was loading the next set phase while the unit was undertaking a process that took more than a few seconds, such as heating up a vessel or transferring materials. Additionally, adding extra controllers to reach an optimal loading state would help with the extended phase transition times.
Budget Limitations
Due to the layout of the I/O, which was still PROVOX™ I/O using the DeltaV™ interface, it was not possible to add additional controllers without significant capital investment to split the I/O into multiple remote drops or convert to DeltaV™ CHARM I/O cards (CIOC). The plant was also unwilling to consider a bottom-up rebuild of the logic due to the cost of such an effort, along with the downtime associated with a full test of brand-new logic.
Solution
- A solution was formulated to move the existing logic as already tested from being executed in phases to being executed in equipment modules. Under this scheme, each phase became one equipment module. This alleviated many of the pressure points the unit faced:
A full retest of logic was not required since the existing, fully-tested logic was only relocated and not changed. - The equipment modules were assigned to new controllers since they had no I/O associated with them. This took some strain off the existing controllers and allowed the batch logic to execute on lightly-loaded controllers.
- While the execution time of phases is tied to the execution time of the unit module in DeltaV™ and requires them all to execute with the same scan rate, the individual equipment modules can have unique scan times. This allowed for some sections of code which were mostly calculations or flags to execute much faster than sections of code that communicated with the control devices in the field.
A proof-of-concept project was executed and lab testing showed that about 85% of the time associated with loading phases and executing initialization logic (setting flags) in DeltaV™ could be eliminated using this new philosophy.
A Safety Issue Required a Project Pivot and Scope Change
During the course of the project, it was discovered that a key programming decision by the initial third-party was causing the system to operate in an unknown state which was a potentially dangerous safety hazard. Hargrove Controls + Automation engineers quickly recognized the gravity of the safety risk associated with the valve situation and worked with the end user to pivot and address this safety issue.
The DeltaV™ logic was skipping over the task of confirming valve positions before moving to the next step in the batch; this issue needed to be addressed before moving forward with the cycle time reclamation aspect of the project. Addressing the lack of valve position confirmation, the additional logic forcing the DeltaV™ to wait for the valve positions to confirm caused even slower cycle times than the project started with, so the gains shown in the initial proof of concept became unattainable.
Results
Hargrove Teammates implemented the additional logic to wait for the confirmation of valve positions, making the operation safer and more consistent. The implemented cycle time improvements were logic driven and did not require a retest of the logic, saving cost and downtime. The logic was moved from being executed in phases to being executed in modules, allowing different scan rates for different equipment and eliminating the associated dead time. The equipment modules without I/O were assigned to new controllers, allowing the batch logic to execute more quickly on lightly-loaded controllers.
The completed project made the process safer and recovered 30% of the lost cycle time, giving an ROI of well under one year.
