By Bruno Maurer
Last August, we got a call from Mark Lauterburg, engineering manager at the Kimberly-Clark paper mill in Niederbipp, Switzerland, located between Zurich and Bern, about an hour's drive from our facilities at Logicpark (www.logicpark.ch) in Thun. Lauterburg was working on a real-time quality management system and was having some difficulty with his OPC servers and reliable data connectivity, so he contacted us as local distributor for OPC software to help resolve the issues he was facing. So the following morning I met him in the mill, and he explained the situation.
"We can store images of every inch of a 3-ton base sheet reel in an SQL database and refer to it weeks or months later, but we need to do more," Lauterburg told me. "To get the camera system working, we must refer the actual produced grade, machine speed and other important data from the distributed control system (DCS)."
To collect data in this integrated way, Lauterburg needed to connect his camera systems to the production lines' ABB System 800xA DCS (www.abb.com). This would allow him to establish direct, real-time connections between the paper-making equipment and cameras, and enhance the quality of the stored data.
"The vision quality management system is one of those investments with significant savings potential, and we wanted to get the most out of it," explained Lauterburg. "Logicpark seemed to be quite expert in working with OPC, and we were confident that they would help us with our data connectivity issues and get everything working."
Kimberly-Clark is a global market leader in hygiene products, and it owns several manufacturing facilities in Europe. The Niederbipp plant is one of the newest. It was substantially rebuilt after a fire in 1996 that destroyed much of the equipment. Because it was recently upgraded with a new drive and control system, the mill's tissue-making machines produce paper at speeds up to 1800 meters per minute. (Figure 1) This kind of production speed requires very sophisticated quality control systems. At these speeds, holes and other defects in the base sheet are not visible to the human eye. As a result, highly sensitive camera equipment is required to detect these defects. For this reason, Lauterburg also recently installed process and quality vision systems on both production lines. These multi-megapixel cameras, called "sheet brake cameras," capture over 1000 frames per second to help identify, categorize and trace any defects in the base sheet.
Our company, Logicpark, is a software engineering firm focusing on data management for industrial systems. Founded in 2003, we implement, support and optimize MES systems, and offer shop-floor and ERP solutions in conjunction with our partners. Our staff leverages its experience in computer science, project and process management, and marketing to provide comprehensive, enterprise-wide solutions.
Cameras and Control
On the shop floor, Lauterburg introduced me to Jan Tschudin, Kimberly-Clark's project engineer, who showed me the equipment. When the cameras were installed, Tschudin had hoped that making the connection would be straightforward because both ABB's DCS and the camera system were OPC-enabled. OPC is an industrial data communication protocol that allows any kind of hardware with an OPC server to talk to any OPC client software, such as a SCADA system or HMI. At Logicpark, we make every effort to implement and support OPC. We do our best to educate our customers and contacts about OPC, and even created a special website for this purpose because we feel OPC is an excellent industrial standard.
Basically, the ABB system had an OPC server and the sheet brake cameras had an OPC client. It seemed like a straightforward connection, but the DCS and the camera system were on two different networks, protected by firewalls. This was the cause of the problem.
Figure 1. Kimberly-Clark's paper mill in Niederbipp, Switezrland, was recently upgraded with drives and control systems that enable its tissue-making machines to produce paper at up to 1800 meters per minute.
"The quality management system runs on a separate virtual LAN from our factory automation system because the sheet brake camera system is running as pilot system at our facility," explained Tschudin. "The producer of the sheet brake camera system has been working closely with us during the installation and afterwards, implementing improvements by remote access from outside the country. We needed clear separation between the two systems, but also to transmit the relevant data from one side to the other."
At this point, I realized that Tschudin and the mills were going to need an OPC tunneling solution. OPC is based on COM, the same Windows protocol that allows you to display and update a Microsoft Excel spreadsheet within a Word document. COM is a good foundation for OPC, but its networked version, DCOM, was not designed for industrial use. It is well-known for being difficult to configure. It also responds poorly to network breaks and causes potential security risks. The typical approach to configuring DCOM for a factory automation application is to open all TCP ports on the two networked machines. This may be acceptable if the two machines are on the same network, but if either of them is behind a firewall, then the security risks can be very high.
"We had been trying to run this system using DCOM, but it was a constant source of frustration," said Tschudin, "The connection would be stable for a day or two, and then it would drop, and we'd have to manually reconfigure the system to get it working properly. We lost large amounts of valuable data that way."
Conduit Between Networks
Fortunately, OPC tunneling eliminates the need for DCOM. An OPC tunneling solution converts the real-time data stream into TCP before sending it across the network, and then turns it back into OPC at the other end. There are several OPC tunneling products on the market, but not all of them provide the robust connectivity that Tschudin needed, combined with the flexibility to configure it for the unique requirements of his system.
Tschudin and I discussed the pros and cons of different approaches. He and Lauterburg had considered using OPC UA, since it is not based on DCOM technology, and thus eliminates the need for OPC tunneling. However, the technology was still in development, and implementation was low. There were no OPC UA servers available for their hardware, and they needed something that would work with their existing system.
Finally, we chose the OPC DataHub from Cogent Real-Time Systems Inc. (www.opcdatahub.com) because it provides a robust tunneling connection and is easy and flexible to configure. We installed one OPC DataHub on the sheet brake's firewalled system computer and configured it as an OPC server for the sheet brake's OPC clients. Then we installed a second OPC DataHub on a utility server on our own firewalled network. This second OPC DataHub was connected to the DCS' OPC server using DCOM. That DCOM connection was relatively easy to configure and reasonably stable because both machines are on the same network, so we didn't have to deal with firewalls there.
Figure 2.Two OPC DataHubs, one on the paper machine's sheet brake computer and another on the mill's utility server, are configured with an SSL tunneling connection that allows the DataHub on the utility server to get data from the DCS OPC server. When the tunnel is activated, the OPC DataHub on the sheet brake side gets a complete copy of all the configured OPC points on the DCS.
Next, we configured the OPC DataHub on the utility server to get data from the DCS OPC server, and then configured a tunneling connection between the two OPC DataHubs (Figure 2). We opened one port on each firewall to allow the connection, and for security reasons, configured the OPC tunnel to be an SSL connection. When the tunnel was activated, the OPC DataHub on the sheet brake side gained a complete copy of all the configured OPC points on the DCS. With a few mouse clicks, we configured the necessary points that the sheet brake system needed, and by lunchtime of the same day, we had a working system.
Of course, there was some fine-tuning involved. Initially, we configured the OPC DataHub to read all the points in ABB's DCS. Since there were a lot of points, that slowed down the start-up time significantly. So, we changed it to connect only to those points that the sheet brake system actually needed. This reduced the start-up time to a fraction of a second. Tschudin and Lauterburg were pleased with the quick work, but needed to test the system for several weeks before deciding to go ahead with the implementation.
The system now has been working for months, and the benefits are clear. "With the vision quality management system connected to our DCS in real time, we can gather important data, such as the machine speed, grade number and grade name, when a particular defect occurs," said Tschudin. "This is particularly helpful when we plan for the use of the paper, such as for facial tissue, paper towels, paper napkins and so on. We have now equipped our second tissue machine line with an identical system and have resolved other problems in the plant by using OPC tunneling."
Bruno Maurer is head of solutions at Logicpark in Thun, Switzerland.
