Baseline your system or else
In this Automation System Integration blog post, Anthony Baker learns that the lack of data about how a system has been operating can create a moving target after an upgrade.
Anthony’s customer required an architectural change to a control system to support some new functions, a conversion from a two PLC (programmable logic controller) system to a three PLC system. All the old interlocks were mapped and moved, and new interlocks added between PLCs. All the DA (data administrator) servers, Invensys Wonderware ArchestrA objects and Wonderware InTouch HMI software tags were reconfigured for the new setup. In short, all items in the checklist were complete.
The new architecture was installed Saturday morning, and a whole bunch of test cases were run over a three-day weekend, to make sure everything was still working, and to tweak all of the control timing for the new response time. Everything looked good, so Monday night, it’s time start-up production again. And everything looked good in production too; just some minor tweaks here and there. Not everything can be caught in testing, so this was expected.
On Tuesday evening the client appears:
Client: “We’re getting more products not sent to the right location.”
Immediately questions start running through Anthony’s head:
- What could be causing this?
- Are there mechanical issues?
- Is the system not setup correctly?
- Is there a communication or network issue? I think that has that happened before.
- Why hasn’t this been brought up earlier? It looks like everything is running just fine.
After looking around for some possible causes, Anthony can’t really identify anything that is causing this issue.
Client: “We are still seeing more products showing up in incorrect locations.”
Anthony: “I can’t really find any issues, how much more product?”
Client: “More than before. We usually get 120/160/180 per shift, and now we’re seeing 160/180, but last shift we got 300.”
Anthony: “Well 300 seems like a lot more than usual. Something else must have gone wrong.”
Client: “Maybe it did. I don’t know really. I just know we’re seeing more than before these changes were put in.”
By this point Anthony is tearing his hair out trying to find the problem.
Anthony’s manager: “You’re spending a lot of time on this. How are we going to know when we’re done?”
Anthony: “I don’t know. I’ve fixed a bunch of things that would have existed before the change, but they keep telling me that it’s more than before, or it’s too much in general.”
Anthony’s manager: “If now it’s too much, how much is right? 100? 50? 0? What’s the target here? Do we know for sure what they had before?”
Anthony: “I don’t know. They don’t have historical data. I heard one guy say six per shift was expected...”
This continued until all ideas were exhausted, along with Anthony. In the end, it got down to a count under 30 per shift, much lower than it was before, and the client was happy. Anthony fixed some things that had been in the code since nearly the beginning of the project, but hadn’t come up before.
If you’re going to be making a change or improvement to a system make sure you have the baseline data on how it operated before, in production. Your test cases won’t always show all the problems on a complex system.
- Anthony Baker strikes again: Anthony Baker is a fictitious aggregation of experts from Callisto Integration, providing manufacturing consulting and systems integration. This blog provides integration advice in plant-floor controls, manufacturing execution systems (MES), and manufacturing consulting, from the factory floor through to the enterprise. Andrew Barker, P.Eng., Callisto Integration, compiled the advice. www.callistointegration.com