A common theme in this blog revolves around doing upgrade projects with functional descriptions and incorporating new system features instead of copying the original system. Here is a short, recent example related to applying these concepts.

We have been working with a long time client to reach a budgetary cost to upgrade from their existing ABB platform with its technology roots in the 1980’s to our current System 800xA product. By the way, the process is mostly batch and a large amount of the functionality is still embedded in “batch” structured text format in the controller logic along with having
a batch manager to execute and control the recipes.

The client is developing a User Requirements Specification (URS) that describes what the project needs to do. That formed the basis of the proposal process to date and there has been no development of the functionality expected. To address that missing piece, there has been an assumption that the control code from the current system would be adapted to the new platform; basically just make a copy of what is now in place, so a functional specification was thought to be unnecessary.  As the process has progressed, one thing that came to light is that a significant component of the cost in the effort is going to be analyzing the old code, especially the structured text, and then trying to convert it into a comparable configuration in the new platform. Without a design document to drive the project execution and ultimately the testing and verification of the system, there could potentially be a large number of engineering hours spent analyzing and comparing the new results to the old basis.

We suggested taking a different approach and develop a functional description of the automation requirements. Rather than copy the old code, take the time to develop a document that functionally describes how the plant does or should operate; a Functional Requirements Specification (FRS). The FRS will provide the basis for code design and a test design. The code design is then free to use techniques and standard solutions that optimize the power and features of the new platform to meet the functional requirements rather than adapting to old, now potentially out of date methods and techniques tied to the older platform technology. The expectation is that once the FRS is completed and a more detailed cost estimate is done against that, the project cost will measurably decrease or new features of the system can be implemented for the cost of just copying the old.

The proposal for the FRS approach was presented at a recent meeting between our two companies. The outcome from the meeting was that the approach would be given consideration by the client’s team. To our surprise, a request for proposal to develop the FRS came the very next day. It turns out that once the approach was discussed within the client’s engineering management, it was approved immediately as there had been a very successful project using the FRS approach completed on an upgrade in another facility that has one of our competitor’s products installed.

We don’t know exactly why the FRS was not initiated from the start of this new project, but that no longer matters. The client has experienced the benefits of using the approach of functionally defining the automation requirements rather than trying to execute a modernization as a copy of the old implementation and is excited to repeat the process again. Now this new project is on a path that should provide highly desirable results.

********************************
What do you think?  Is a Functional Requirement Specification important?  Do you use them?  We'd love to hear from you about best practices in this area.

One of the repetitive subjects of this blog has been avoiding the trap of “going cheap” with an automation system upgrade or replacement (August 29, 2011; November 11, 2011; August 13, 2012; etc.). The core emphasis here is to get out the message that making an investment in automation can deliver real benefits, but just replacing an existing automation installation with one specified to do exactly the same thing and nothing else is literally like burning money.

Another supporting opinion on this topic came on January 8, 2013 (repeat of 12/19/2012) in Mark Hoske’s posting on Controleng.com; Automation Budgets: More than Automation. Mark provides several different ideas where benefits can be found and provides references within the Control Engineering publication. The links in his original presentation go to specific articles that highlight examples of the benefits presented.

Mark’s point is that benefits can be wide ranging and therefore the cost of the automation improvements should be shared across most of the facility budgets and not just operations as is typical. Please take a look at his suggestions. You might find a few interesting nuggets to use for your next automation project justification.

Are you just looking at costs, or are you looking at major opportunities to improve your business and your bottom line?

If your facility is in the process of justifying a DCS replacement or upgrade, you are probably struggling with how to justify the cost of the project. Generally the list of considerations looks like this …

• Obsolescence of the older system is creating concerns about reliability and availability of parts. You try to determine the risk of an actual high impact failure that will stop production and cost your company potentially millions of dollars. But that probability does not really seem to be very high because that old, reliable DCS just keeps working every day.
• You consider staying with your current supplier because they have means to capture current graphics and control configuration so you need not re-engineering the system.
• You consider keeping the old I/O subsystem in place because touching all of those old, brittle wires is simply not a risk any one wants to take.
• You want to keep the system visually and operationally the same because it is too risky to force change on your aging workforce.
• You are trying to fit into the same tight spaces and it needs to not interfere with your existing arrangements of interfaces for safety, ERP, office applications, and perhaps dozens of other productivity tools.

After all that old system is only there to control the plant. Does it really have any other real benefit? In the minds of many cost–blinded business managers, generally that answer is, “No, it is just a control system.”

But over the years, what has your enterprise done with that system that is not well recognized by the people removed from it, and represents significant risk when considering the update or replacement of the DCS. The data from it that populates reports used every day to track production, performance, and quality of your products. There have been at least attempts or desires to link the information it contains to your ERP system to try and get as close to real time production status information as possible. Special interfaces have been created to connect it to third party control and information systems to centralize visibility of the information those system provide in your plant like compressor controls, vibration monitoring systems, laboratory systems, PLC subsystems, safety systems … and the list goes on.

What do all of these items represent? Cost. And in most replacement or upgrade projects, that seems to be the main focus, to purchase a system that minimizes costs, after all, “It’s just a control system.”

What so many of these project fail to evaluate is the benefits of installing a modern DCS and making changes to nearly everything to make improvements that contribute to the financial benefit of the enterprise. What if you …

• Evolve the operational philosophy created 15 or more years ago to adopt a sequential methodology being identified by the ISA106 committee to derive benefits from reducing the demands on operators, to drive toward common reaction to abnormal situations, and to capture the knowledge of your experienced workforce before they retire?
• Utilize the intelligence of your smart devices to migrate from your costly reactionary and scheduled maintenance environment to one based on prediction and information?
• Eliminated most of the traditional, direct wired I/O in favor of fieldbus and wireless technologies to move your instrumentation base into fully digital devices that may require new skills and work practices, but offer many advantages in functionality and reduced maintenance (FOUNDATION Fieldbus, PROFIBUS, WirelessHART)?
• Eliminated most if not all of those custom-built interfaces for reporting, ERP integration, and third party system integration in favor of standardized connectivity available now and into the future?
• Adopt a process safety environment where safety automation is fully a part of the control design, does not require an interface, and shares all of the features of the DCS like asset management, alarm management, history and much more?
• Integrate control and visibility of your electrical systems into the DCS to significantly improve visibility and control over one your most costly variable resources?
• Invested in a modernized and ergonomic control environment that significantly improves the effectiveness and alertness of the operations staff and has the additional benefit to be a place that attracts new, young talent into your workforce as your older resources retire?

And just one more what if … what if your competitors are gaining these advantages when they are upgrading or replacing their aging DCS and your enterprise is not?

No one has unlimited capital resources for projects, but without a serious consideration for making significant changes to gain benefits, the effort will result in being just a control system and not a true asset to the enterprise.

********************************

I realize this was an extremely long post, but an issue that I feel strongly about.  I'd love to hear from you.  What are your thoughts about upgrading your DCS???