Stephen Reilly, ProSys
Earlier this year, one of ProSys’ clients completed the converting of its tank farm, upgrading from a Honeywell TDC DCS to a Honeywell Experion PKS. With thousands of I/O converted from the original DCS arrangement of “tag.parameter” to the newer DCS format of “tag.block.parameter” and all other connection settings equally and meticulously accounted for, it took an extensive effort both from the client’s staff and from the consulting companies that assisted with the network configuration, HMI graphics assembly, and general project management needs. Right before operator training commenced on the new DCS, ProSys upgraded the client’s installation of Dynamic Configuration Software to its more flexible, DCS-neutral alarm management platform, AgileOps.
With the company’s specialized insights and expert knowledge of the inner workings of both DCS platforms, the seemingly-gargantuan task of upgrading the entire alarm management system, was successfully completed with relative ease overall. The alarm management system maintained rationalization records from that LCN for ~2,000 alarms of which ~80 had dynamic settings across ~40 process systems. The new DCS was recognizing/instantiating an additional ~15,000+. I would be remiss though to say it went off without a hitch, and with that client expecting ProSys to help them out for future alarm management system conversions on their remaining LCNs, there are a few things my coworkers and I, along with any other potential clients, should be aware of for such a procedure.
First, one must ask, are there any pending gaps in the client’s original alarm management records? A project’s execution is only as strong as its foundation. For full team confidence, it helps to ensure that all alarm boundaries properly define such fields as their Cause(s), Consequence(s), Action(s), Time to Respond, and Severity for the board operator to get a complete idea of how to respond when the associated alarm annunciates. If there are actions items remaining from the original work, it is reassuring to have them closed out. If an alarm is deemed to be dynamically managed, it is crucial to have the appropriate timers indicated accordingly. In short, with incomplete records, delays emerge in completing the implementation, and if the client does not prepare time in the whole conversion schedule to address such delays, it can consequently impede our progress.
Second, as the consulting company assisting on the conversion, have we received the latest information? Two months before arriving to site, ProSys had received Honeywell Experion configuration files in .XML format and assurances by the firm charged with configuring the new I/O scheme that they were not expected to be changed any further. So, we ran our .XML-file-reader program and generated the list of loaded and configured alarms, and then we prepared to migrate the alarm information accordingly. However, after completing AutoDiscovery in AgileOps and then reviewing the Honeywell configuration, I learned that some alarms that had supposedly been “loaded”, had not for various reasons, leaving me scrambling a bit at the last minute to reconcile alarm information. Thus, the next time I do this, I advise that we get an additional configuration update right before we go to site to avoid this re-work.
Third, are all alarm types from all relevant alarm sources properly defined? While our .XML program read in and recognized potential alarms directly built in the Control Builder program, I had to reconcile points at the last minute built using the Profit Blending and Movement (PBM) software, used particularly for inventory and storage operations like the tank farm we converted. You should account for alarms from all sources.
With these three major takeaways, I’m fully ready to get to the next alarm management system conversion, so if there are any questions or interested participants, let us at ProSys know!