Further Thoughts from Sandy Vasser on Reducing Automation Complexity

Summer is winding down, and usually this time of year is good for finishing some unfinished thoughts that may have happened in June and July. A few months ago, we wrote a blog about reducing the cost and complexity involved with generating HMI graphics in process automation systems. Sandy Vasser and I discussed the results of this discussion, and Sandy had some further thoughts to share on reducing customization and custom engineering costs in process automation systems, with an emphasis on HMI. Here’s what Sandy had to say:

Using P&ID Depictions in HMI

“I am not convinced the historical practice of using a version of the P&ID depictions for the HMI displays is the best depiction for HMI displays. I think there is at least one major supplier that is considering something completely different for HMI displays. Although I assume we will continue the practice of using some depiction of the P&IDs for the HMI displays. 

Key Elements of the “It Just Happens” Initiative

We Need to Stop Doing Similar Things Multiple Times

“One of my principles for improved project execution practices is that we have got to stop doing very similar things multiple times for different purposes. We have got to do it once and then have means to modify the one product for use in other purposes. An example of this is using the Cause & Effects to directly program the logic solver for the SIS or using the power system analyses results to directly program the protective relays.”

“I think one reason why we continue to have very disconnected activities that results in doing very similar things multiple times is that we have experts in a particular field that feel that if they do something completely independent of the other activities, they will get a better result. That is why most of our project execution practices are very customized and independent from other activities. This must end.”

But We’ve Always Done It That Way

“I also believe that many experts believe that if they take historical practices and automate them or make them more user friendly or easier to use, that is success. I think that is okay PROVIDED the practices has been challenged to insure it is necessary and that no other completely different and more efficient and effective practice is possible. However, this check is rarely done. I also believe that folks who believe a different approach is better will spend all their time proving why an alternative approach is wrong rather than finding ways to make a more efficient approach work. “

“I think that to get a true more efficient and effective practice, there must be people involved that have no bias for the old practices. You almost need an independent group to think completely differently without the bias, baggage, and burden of the old practices. If a committee only consists of those that have use the historical practices for 10, 20 or 30 years, it is unlikely the resulting practice will be significantly different. “

“I think one of the reasons why we continue to follow historical practices is that the senior staff train the younger staff to follow the historical practices. Our senior staff should be teaching the principles, not just specific procedures and practices."

We Can Facilitate Change in Automation

“I am not always supportive of developing completely new practices through committees consisting of topic experts. There are many examples of practices developed by committees that are very complicated, described in very large documents, includes some compromises to achieve buy-in and requires experts to deliver the product on a project. We got much better results by working directly with each supplier. We defined the problem and what we wanted to achieve, shared it equally with all the suppliers and then let them loose to develop the best solution.

“If we had used a committee to develop intelligent, single channel I/O, we could still be waiting for a commercial product. I think if you want to get something completely different for HMI displays, I would go to all the suppliers with a detail list of what you want to achieve. Users should be defining the problems and the things they need achieved and then let the suppliers develop the solutions. As much as some users believe they are the experts, they are not for developing commercialized solutions.”