ARC recommends you treat a major control system upgrade or migration project as you would any strategic business opportunity. By following the process outlined in this three-part series, you will greatly enhance your project’s successful outcome. (read Part 1 and Part 2)
Once your decision criteria are in place, the rationale for evaluating the supplier approaches should be to look at anticipated performance and reliability. Standard products are best, and this is what many migration products have become. They are designed for purpose, tested and warranted, and can be expected to have the right performance and reliability characteristics. You should be cautious of migration solutions that do not use a standard, productized approach.
The same holds true for the tools used by suppliers to automate procedures such as graphics conversion and control-strategy conversion. Many suppliers treat these as standard products within their own organizations. Several suppliers are just developing these tools, which, in some cases, have not yet reached a level of functional reliability or even full functionality. Migration solutions that depend on third-party components to satisfy intermediate needs, but are not tested and warranted as standard products, would not be expected to have the characteristics of standard products.
Another important consideration when taking the phased approach is the need to support common services; the glue that holds a system together through all migration phases. Common system services refer to system health, common time and so on. At different times throughout the migration, components will be removed and replaced. To maintain the integrity of the system, these components need to embrace common system services natively.
For phased replacement, or when integrating foreign equipment, I/O and hardware selection should be based on the breadth and depth of a particular project requirements and the supplier’s ability to address these. For code conversion, proven tools rank high in the list of selection criteria. The ability to convert program code such as sequence logic is next in rank, followed by block code and graphics and the ability to reconfigure legacy structures into S88 standard structures.
Request for Information Can Help You Decide
While your team is developing and defining the attributes of your new control system, this is an excellent time to develop a request for information (RFI) document that you can send to all prospective suppliers. Of course, it is advisable for you to narrow the list of suppliers down to a reasonable number prior to sending the RFI. The ARC-developed STAR selection tool can help in these areas.
In the RFI, you want to ask the supplier questions as to how their solution and services can be applied to meet the requirements you have developed. Migration solution supplier decision is not just a technology replacement decision; but an important business decision as well.
Some of the RFI questions should be designed to help you understand how the supplier’s new system is built for the purpose you envision. The following are some of the system capability issues you should consider.
Networking and Connectivity
For networking and connectivity, gateways should be kept to a minimum and proprietary protocols should give way to standard and de facto standard protocols in the target or new system. This should be Ethernet-based at the workstation level and above. Field device and instrumentation communication should support what you have installed and plan to have over the roadmap your team has developed. Obviously it is critical for the system to be able to support all standard buses such as Foundation Fieldbus, Profibus and HART. In addition, you should inquire about the supplier’s ability to support wireless protocols such as ISA100.11a and wirelessHART.
Modern control systems also support connectivity and integration with manufacturing operations management/production management-type applications. Those that adhere to ARC’s Collaborative Process Automation System (CPAS) principles will often do a better job of integrating these applications with the control environment. For systems and applications that are not a part of the control system supplier’s products, it is important for the supplier to support connection protocols such as open platform communication.