Are there any examples of where analytics were applied to a legacy PAS configuration prior to modernization? Specifically, was the legacy configuration migrated via bruteforce or was an effort made to understand the content of the configuration? Were similar loops identified? Were custom loops identified? I am seeking input as to what analysis steps are taken to translate a legacy configuration to DeltaV.
By legacy are you referring to legacy Emerson systems? I have recently migrated an old Honeywell system to DeltaV. We migrated the simple configuration using tools where we could, for example we mapped the existing module types to DeltaV PCSD module types and the same for dynamos. For the more complex logic we spent some time with the customer and the Emerson migration team understanding the objectives and required functionality of the logic (effectively reverse engineering). We then built complex loops in DeltaV which performed the same functions. It was easier this way as the function blocks in DeltaV did not always perform the same as the ones in Honeywell. It took a bit of work but it was worthwhile. One of the interesting outcomes was that the customer often questioned the necessity of the loops and often replaced them with simpler configuration when they realised they didn't use most of the functionality.
In reply to scottjturner:
I am referring to competitive systems like Foxboro, Honeywell, Bailey and Siemens Moore APACS. Although, the same analysis can apply to Provox and RS3. What tools did you use to migrate with and what purpose did they serve? For the complex loops, were Functional Specs written?
I am keenly interested in where tools were used, how and what they are. Where are these tools, who owns them? We have the ability to do analysis that will tell us the 'class' (repetitive, think DeltaV module templates) and custom work. I believe this type of capability would be very useful to a migration team and I'm trying to promote their use. Is there anyone using this template and custom approach?
Often, the granularity of the legacy control configuration is small (think Bailey function blocks). In Foxboro I/A, the AIN, PID and AOUT blocks simplify down to the PID controller in DeltaV. It is good that your customer was able to remove 'dead', needless or overly complex functionality when they converted over to DeltaV.
In reply to Cody Long:
We have good experience of this in the European offices. Recently in the UK we have completed a migration of a competitive system on the Valero Pembrokeshire refinery (Honeywell TDC). We used the dedicated migrations team in our Pune office. This dedicated team has developed a number of tools and techniques for reverse engineering the legacy system code. They have engineers with who have come to Emerson with good levels of experience working on other systems and utilise that knowledge to understand how to migrate these systems to DeltaV. It worked well and would recommend contacting the team and asking them for assistance.
We did write functional specifications for the complex loops. We wrote specification to identify what we considered complex and therefore what should be treated outside of our standard tools and techniques. For these identified loops we developed specifications where we documented and reverse engineered their existing FBD's to develop the equivelant logic in DeltaV.
I have done a number of conversions and there are a number of approaches. From a strict engineering standpoint we like technical perfection and would analyze every loop for performance prior to moving to a new system. From a practical standpoint, the accounting folks prefer we actually finish the project at some point. The best, as usual, is a balance.
My preferred approach is to start with the full list of loops/points for configuration. You will find the majority of them are simple configuration templates and don't need much other than some decent tuning after the conversion.
This should leave the points that have some type of advanced or complex configuration. Review each of them and determine how to configure them best in the new PAS. New features may simplify the work. So far, not much different than what Scott suggested.
Much of the advanced configuration is because of control schemes that require some additional thought and maybe a little updating with a new, more modern system. Hopefully, this will not leave you still with a huge list of complex loops. These remaining loops are probably complex for a specific reason (financial, environmental, safety, etc...) and you may need to hunt for the original purpose in a legacy configuration.
These remaining loops should be reviewed in detail to determine if specific changes to them can justify the time involved in re-engineering. Some may gain in performance but the value does not justify the cost. Those that do I would include re-engineering in the cost/scope of the project as well as what benefits you expect.
Lastly, I always like to choose a couple of opportunities to showcase the features of the new PAS. You can usually find one or two that really show what the system is capable of once it is installed. Many upgrades are justified on the basis of obsolete and unsupportable hardware. That doesn't mean there is not a chance to show what can be done. This is one of the main reasons I go to Exchange, to see if any of the presentations spark an idea for an improvement. Many of these do require some updates to field instruments or piping and could be included in the project and justified on their own merits.
Sorry I am a little slow to the response.
Cheers, BC
In reply to BC Spear:
Regarding technical perfection, we have tools that fully identify the list of loops/points for configuration. Our experience is that within a legacy configuration there are definitely repetitive (classed/templated) loops as well as custom loops. Our tools identify the percentages of custom configuration and templated loops so that the level of effort for conversion can be better estimated. Our tools have the capability of determining the actual loop structures directly from the legacy configuration without any other information. As a simple example, our tools can quickly determine that a loop contains 3 analog inputs, one PID block and two analog outputs. These reverse engineered loops can be represented in a Visio drawing to document the as found functionality.
Thanks for the rich response.