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:
- 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.
- 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.