Here are a few words from my colleague Alicia DuBay who has just returned from the spring meeting of the Center for Operator Performance (COP).

I have not been very deeply involved with the COP for the last few years due to a new job assignment.  However, it was fantastic to get back in touch, not only with the people, but with all of the existing and new research projects that we are funding.

Since I last attended a COP meeting, there have been quite a few new projects started or continued with additional phases.  These projects include a continuation of Event Prediction, Effectiveness of various Training Methods for process operators, Data to Information Handbook, Alarm Formatting and Presentation and perhaps most exciting - an update on our Overview Displays project.

While all of these projects are valuable and the research is providing some terrific insights into expertise, how operators learn and some guidance on grouping and visualizing data, the Overview Displays project is the one I am currently obsessed with.  This project is member run and is focused on taking some of the results from our completed research, combining that with member experience and developing a set of “best practices” for creating a plant overview display for use by operators in a control room.  

Of course such displays exist today, but little exists in the way of defining the best way to aggregate and display the necessary data.  We are currently part way through creating the best practices from the results of our research and from reviewing existing graphical displays to distill common mistakes and areas for improvement.  Once these guidelines are in place, a new Overview graphic will be implemented at one of our member company’s facilities. 

Once the operators become familiar with the new display, additional research testing will be done to measure the improvement in operator performance based on criteria like how long it takes to find critical information or reaction time to a critical alarm.  This project will provide a real world example of how to apply this research and will be supported by metrics quantifying the improvement in performance.  I can hardly wait to see the results.  I hope to have additional information to share after our fall meeting.

You can find additional information on the Center for Operator Performance at www.operatorperformance.org.  Check it out.  We are accepting new members.  As always, member or not, we would love to hear your thoughts on our Overview Display project.

I hope you have enjoyed this article by Roy Tanner of our System 800xA Product Group.  Please let us know what you think of the role of automation systems in management of change.

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

Conclusion

Change is a necessary part of today’s operations in production facilities and therefore management of change is key in reducing risk to the process, business, environment and personnel. Though management of change is much more than features in an automation system, these features can help facilitate management of change in various ways.  Compiler checks, change verification reports, the use of libraries for step-wise change introduction, and simulation testing are all ways that most modern systems have available to help management of change process.  However, probably the best way to perform impact analysis involves comparing the modified application or program to the original using the actual live inputs in order to detect potentially hazardous changes to the process.  This is not commonly found but has been proved to be an invaluable asset for reducing risk as it detects possible differences in calculated outputs which cannot be found in any other testing scenario.  To quote a well known figure “Change ….good ;  Fire ..Bad”.   

To download the white paper, please click here  and don't forget to visit ABB’s Power of Integration Knowledge Center on Control Global.

This is the fourth in a series of posts by Roy Tanner on management of change.

Impact Analysis using actual inputs to the application – the final frontier in change management

While simulation testing will validate an application’s functionality relative to the its requirements, it cannot show the actual differences between the new and the original application in order to unveil any  dynamics that might exist as the consequence of the new application calculating different outputs. For example, upon the execution of a newly downloaded application or program, the new application could result in closing a valve where the existing one would open the valve.  The result, could potentially have consequences such as poor performance, shutdowns, environmental impact and increased risk to safety of plant personnel.   

Therefore, true impact analysis can only be accomplished where the modified application or program is downloaded to the running controller in parallel with the original and, using actual inputs, the user can “evaluate” the resulting differences, if any, between the “evaluation environment” and the actual, running “production environment”.    Though this feature is not common in all automation systems, it is a powerful tool that provides two distinct benefits.  First, it significantly reduces the risk associated with making application or program changes in the running process and second, it improves overall efficiency by avoiding production stops, poor optimization, and costly downtime.

A feature of ABB’s System 800xA was developed in collaboration with Dow called “Load-Evaluate-GO “ or sometimes referred to as “LEG”.   This Load-Evaluate-GO feature enables the user to add programs or modify configurations and then load the new application into the running controller in parallel with the application actually running production.

Using actual live inputs, the “evaluation” version of the application calculates the outputs that would go to the field if it was the actual production application.  The two environments can then be compared directly to the actual running application via difference reports of signals, alarms that may be generated as well as an operator interface view that is generated separately from the runtime environment.  This parallel universe is called “Evaluation Environment” and can be called up so that the user can see what an operator would see as part of the evaluation. 

Once the user evaluates the new program or application’s behavior based on live inputs, they can commit to the new program (“GO”) which replaces the running application OR the user can back out of the process with the original program still running production as it was before.

Because of the very stringent management of change process and its difference reporting capabilities at each stage of the loading process, the LEG toolset forces the user to think about the differences reported in two major situations:

1. Static differences: all the differences between the running code and the code to be loaded are flagged. If a difference is a surprise, load process can be stopped and the situation can be investigated. Also the inverse is the case here: one is expecting a difference and it is not reported. This indicates that a program part that was supposed to be loaded is not incorporated in the load set.
2. Dynamic differences during evaluate mode: even if the static difference test has not identified issues, there is still the risk of calculating a different output value for one or more outputs between the old and new application. Those differences are reported and offer the ability to the user to intervene prior to activating the application such as putting the output of a certain loop in manual or back-out of the loading process altogether.

Take, for example, a critical process in which changes need to be made.  Even though the changes could be extensively tested and simulated in an off-line environment, using System 800xA’s Load-Evaluate-Go feature could reveal that downloading the new, modified application would have resulted in a particular control valve’s output increasing by 10%.  Without the capability of detecting differences in outputs during implementation of the changes, plant operation may have been unintentionally disturbed, impacting the end product quality or worse a plant trip.

Can you test changes against the live process?  Would this be valuable?

In the next and final installment, you will be able to download the entire article from the ABB Power of Integration Knowledge Center on Control Global.