“Open” seems to be the fashionable word at the moment and we can be see it in everything from open-source software to open-administration governments. Even our own controls engineering world sees a significant share of this trend. Communication is going open, and programming languages follow open standards.
Openness facilitates cooperation between the parties involved in a project. Because of the concept of intrinsic transparency, instead of receiving a list of specifications, the next person or team in the design process get to see the reasoning behind these specs. When going at the task assigned, they can work to fulfill the intended function, instead of blindly trying to meet the specifications. This typically can be the case in selection of sensors, where the measurement range needs to cover everything from stopped equipment to running above spec. However, the accuracy usually only needs to be good around the typical operating point. It even could be that the sensor can be good enough only if special precautions are taken. Knowing the reasoning behind the specification helps to decide between different design options that, in the end improve cost, efficiency and performance.
In a recent efficiency-improvement project for a pulp-screening room, we first approached each object of the system in isolation and identified significant improvement potential. When we looked at everything as a whole, we quickly came to a common conclusion that the worst-case scenario didn’t occur everywhere at once and, because of that, we could make further improvements, in the end doubling the savings we would have realized from a localized approach.
Openness also makes a more extensive review process possible, where more parties can participate and contribute their knowledge. Working in a preexisting site, there are always parameters that change and routines in use that a designer doesn’t anticipate. These things might or might not come up during review sessions, but if the underlying material is available, all conscious assumptions can be found and verified.
We faced one such case a few years back with a pulp-transportation pipe network, usually a straightforward process. However, for some reason, the pulp occasionally stalled in a pipe, despite calculations showing that it should not happen. After much measuring and testing we realized that during certain flow rates with a consistency deviating enough from the nominal value, a side stream made it impossible to build up enough pressure in the pipe. It turned out that the calculations assumed a slightly different type of pulp and very small deviations in consistency. Together they caused stalls in the pipe. Knowing this, one additional pressure sensor and a slightly different control strategy eliminated the stalls.
Openness inherent in transparency provides better documentation for maintenance and future improvements. Since the reasoning is available, it’s easier to find sources of malfunctions than it is with only program code and mechanical drawings. In the same way, retrofits or expansions are helped along with more information about the intent of each part. Typically, equipment has been lacking in measurements and the PLCs missing useful functionality. In both cases, we controls engineers have to write code to work around the limitations, often resulting in adequate but less than ideal solutions. More rule than exception, the resulting code is unwieldy and illegible.
We as control engineers have most to gain by an open engineering culture. Often the last step in the design process, we are the most dependent on the work of others. It’s important for us to know if the force constraint given is because of the mechanical strength of the product or the limitation of the hydraulic cylinder, and to know if the constraint is always in force or only during startup or continuous operation. We need this information to do our job, and we prefer not to reverse-engineer it when the information is readily available.
Moving up a step to system integration, the same principles apply. If the machine is sensitive to thickness variations, the equipment chosen upstream should have tight thickness tolerance, sacrificing other properties. In a general sense, this is already done today. But without specific knowledge about how that parameter affects it, it’s nearly impossible to weigh that loss. Armed with all knowledge and information accumulated during a project, we can contribute more to it, making the end result better.
Choy-Hsien Lin is development engineer at Stora Enso Newsprint and Book Paper (www.storaenso.com) in Hyltebruk, Sweden.
