Digital Instrumentation and Control Upgrades

A computer system hardware or software upgrade can be a daunting challenge.  Multiple industries both regulated (nuclear, biotech, pharma, food, medical device, etc.) and unregulated are facing aging hardware and software which is no longer maintainable or supported by vendors.

In most cases there is an entering project requirement to make the upgrade with minimal down time.  Down time is affected by two critical phases of the project:  Equipment and software installation sometimes referred to cutover and system testing including validation.

Automated system infrastructure and hardware installation or cutover time can only be reduced to a point.  However, we can plan for initial installation to occur during operations and limit the production downtime.  Such pre-planning will have to take into account space availability for two sets of equipment (the functioning existing system and the newly installed system ready for cutover).  The team can create mockups and practice the cutover.  The electrical installers can pre-cut and pre label wires.  The proposed integration with existing field equipment, controllers, terminals, panels can be verified at the vendors factory acceptance.  Thus answering the question of will the new equipment integrate and function with existing equipment per our requirements.

Automated system software modification and upgrades create a more difficult set of risks for the team to identify and take action on.  One of the first topics the planning team will focus on is equivalency.  How can we prove that the new system works like the old?  In proving that the new system is 25%, 50%, or more equivalent to the existing system you can greatly reduce the burden of verification and testing and therefore reduce down time.  Such a philosophy greatly increases the schedule burden and risk to the software, automation, and validation teams.  Those teams are used to being at the end of a project and on the critical path, but now we have the risk of the initial assumptions and arguments of equivalency proving to be incorrect. 

Equivalency is a project risk due to the entering argument for the project…we can do this upgrade only if the downtime is within a certain time period due to the impact to production.  The Equivalency argument is that which got us under the wire for down time.  Hence there is little room for error in defining the impact of the proposed upgrades and the verification/validation strategy required.  To combat the equivalency risk we enter the world of extreme planning.  Extreme in that the team must plan for all contingencies and be willing to spend the time and money to invest in the success of the equivalency argument. 

Planning will take the form of multiple risk assessments, design reviews, system prototyping, factory testing, site mock-up and pre-cutover testing.  All of these efforts will enable the team to answer the question "Are we ready to impact production and successfully bring the new system online?"  The post-cutover verification should be a reduced set of testing to challenge assumptions, prove our risk mitigation strategies, and verify critical functionality.

Don't forget the party to celebrate the successful project!

http://iom.invensys.com/EN/Pages/IOM_Nuclear.aspx