Dang. It wasn’t supposed to be this difficult. By now, industrial networks were supposed to be completely interoperable and seamlessly humming along in unison. Users were supposed to be able to plug and play any devices they wished into a safe, secure and totally open network.
Well, reality is having a little bit of trouble catching up to this long-sought and often-over-hyped fantasy. Of course, new components and networks run into legacy devices, twisted-pair fieldbuses collide with point-to-point hardwiring, everyone bumps into Ethernet, enterprise systems stick their noses in, and someone starts talking about wireless. Oh, and plant-floor engineers have running arguments with IT staffers, assuming they’ve ever met or talked to each other at all.
Dissolving Boundaries = Stepping on Toes
The historical niches and silos where each type of industrial network originated and grew up have been dissipating. However, most have emerged only to find they don’t speak the same language and there’s far less interoperability and far more incompatibility than their users expected. Even experts in one protocol or network technology say they don’t know as much as they need to about multi-network interoperability.
So, while there’s no magic bullet, there are hardware bridges and gateways, and even some evidence of growing professional cooperation.
“For now, it’s getting worse because the list of networks keeps expanding, their capabilities are crossing platforms, and many networks are being used for tasks for which they weren’t originally intended,” says Les Haman, regional manager for Matrix Technologies, a CSIA-certified system integrator in Maumee, Ohio.
“Usually, most legacy networks can’t be completely replaced, so they have to be supported during and after retrofits, and so we need to keep building bridges to them.”
For instance, Matrix’s engineers recently integrated and replaced much of a proprietary Square D Synet network at AK Steel’s plant in Middleton, Ohio, with Rockwell Automation’s ControlLogix controls. However, Haman says some parts of the old network had to remain Synet, and so Matrix built bridges to the older protocol using third-party Modbus TCP/IP Ethernet. The overall $60 million renovation included mechanical work, I/O buildings, an off-site fabrication room, a hoist and other equipment.
“All that the mill could afford to do right now was to replace the primary off-gas system and add secondary emission collection vacuums and a monitoring system for EPA compliance,” says Haman. “Luckily, there were enough pieces on the market for us to do a prototype and benchmarks, so this solution could be used in a control environment. However, the rest of the plant was all Square D, including the CT probe, flux delivery system and O2 lance probe, and it would have been prohibitively expensive to update all of them. Plus, there were some risks and scheduling that didn’t make it possible.”
What Matrix needed was a common denominator between Synet and ControlLogix. What it found was a stand-alone, third-party, Ethernet protocol converter that plugged into ControlLogix’s backplanes and could use Modbus TCP/IP to have Synet-based devices talk to the ControlLogix network. Haman says the only other option would have been RS-232 hardwiring, which would have been far too costly.
“We were able to help AK Steel save several million dollars that it would have cost to hardwire or replace many of the legacy systems,” says Haman. “Just doing the design, prototype, benchmark and acceptance test was like a little project in itself. However, it made everyone feel better because it showed us options we hadn’t considered before and let us test the capabilities of the new solution.”
It takes a lot of planning to avoid bumping elbows in an industrial network, explains Haman. “You first have to map all the data-flow requirements, such as the kind of information and whether it’s integers or string-type data,” he says. “You also have to determine update rates depending on how fast you’ll need the data. Next, you need to pick which protocol and platforms to use. Finally, you need to draft an interface design specification that has all these requirements in one document, which can help you get your mind around the whole scope of all the data in your system. This one document can help you see and understand what data needs to go where.”
Going With Gateways
Just as intelligent switching and addressing made Ethernet more deterministic and credible, increasingly intelligent gateways and other modules are being used to translate communications and even aid interoperability between many fieldbuses and other networks.
“It’s been quite common for us to see DH-485, DH+, ControlNet, EtherNet/IP and DeviceNet all in the same plant or perhaps encounter Ethernet, SyNet, SyLink, and ModbusPlus all in a Square D/Modicon integration,” says Bryce McBride, senior electrical engineer at Huffman Engineering, a CSIA-certified system integrator in Lincoln, Neb. “However, with gateways, it’s become easy to interconnect networks from different manufacturers. In fact, it surprised one of our users when we told them a Profibus-based hardware solution best suited their application and that we could use a ProSoft gateway to interface it with their existing ModbusPlus hardware. By connecting these two essentially German products, you might say some of the old walls have come down.”
Staying Simple, Separate
While more bridges between networks are becoming available, users report that they have to keep some networks apart because they still don’t interoperate or communicate well, so instead they focus on one networking method.
For instance, Ford and Mazda jointly run their AutoAlliance facility in Flat Rock, Mich., where they manufacture 1,200 Ford Mustang and Mazda6 vehicles per day. The plant uses CC-Link in its conveyors, panel controls, welding robots, paint shop and other areas (Figure 1).
Figure 1: Making Mustangs
Multiple ABB robots apply sound-deadening material to Mustang bodies, while PLC-controlled Fanuc P500 robots spray on finish colors and clear paint at the AutoAlliance plant in Flat Rock, Mich.
Source: CC-Link Partner Association
Likewise, six ABB robots operated by Mitsubishi Q Series controllers and CC-Link simultaneously apply liquid-applied, sound-deadening (LASD) material and joint sealant in up to 12 different areas of each car body before painting. Five different body types—including Mustang’s coupe or convertible and the Mazda6 wagon, hatchback or sedan— can be run through this line. In this four-year-old cell, CC-Link uses laser-scan data to tell the robots when and where to apply LASD and provides communication between the robots to prevent collisions while operating. Also, Mitsubishi PLCs control the paint line, where Fanuc P500 robots apply one of 24 different finish colors.
“We’ve used CC-Link, DeviceNet, Profibus and Ethernet in the paint shop for several years, but it can be difficult for them to get along because they can’t interoperate,” says Joe Bialy, AutoAlliance’s electrical engineer. “For example, Profibus between the vision system and robots doesn’t have a heartbeat. So, when they stop talking every three to six months, we have no way of knowing until the robot starts banging into a car body. We then do process-of-elimination troubleshooting because we don’t know where the problem is located.”
Bialy also reports some problems with DeviceNet communications between the plant’s robots and their end-of-arm tooling. “It’s probably cable-related because they’re constantly moving and flexing, and so they can short out and crash DeviceNet. The only solution is to do more inspections and cable replacement. In addition, he adds that Ethernet-based communications between the robots and the operators’ graphical user interface (GUI) had some problems and possible data collisions during the past six to 12 months. “The GUI also doesn’t communicate back to the robot correctly, and so the users can’t change parameters or switch jobs,” says Bialy.
He reports that CC-Link helps coordinate and communicate between several robots as they move inside the car body at the same time. This allows LASD or paint to be applied in 45 seconds instead of the 135 seconds it would take if the robots worked only in sequence. “CC-Link is the only communications protocol that hasn’t given us problems in the fours years that this cell has been operating,” he explains.
Remote I/O and Intelligence
To better customize its dough-mixing and cookie and cracker machines for baking industry users, Peerless Group in Sydney, Ohio, recently standardized on EtherNet/IP to synchronize its equipment to run in tandem, allow tighter control and streamline operations. However, the builder still had central cabinets full of drives and PLCs and was running hardwire and conduit from its machines to the controllers, which became a problem when the lines reached 250 ft or went to different plant floors. Peerless also needed to keep its network components clean and undamaged despite the high-pressure, high-temperature washdowns and harsh cleaning agents its clients often use.
To meet these networking needs, Peerless implemented distributed I/O to move the control panel from this harsh environment but also implemented Turck’s BL20 EtherNet/IP, terminal-wired I/O to retain the local, plant-floor control it needs. BL20 is IP20-rated I/O for cabinet installation, and substations were installed next to each machine. The substations contained one BL20 system to maintain control for one machine and used cordsets to send data from the substation to the main cabinet (Figure 2).
Figure 2: Relocating I/O for Dough
Dough and cracker machine builder Peerless Group implemented distributed I/O and an EtherNet/IP network using terminal-wired I/O in a cabinet and in substations next to each machine.
Source: Turck
“We chose BL20 because it’s easy to troubleshoot at the machine,” says Eric Cruse, Peerless’ controls engineer. “And converting to distributed I/O cut our installation time in half. Not only has distributed I/O with a standard network protocol lessened our installation time, it’s given us the flexibility to put I/O at the point where we need it to get EtherNet/IP.”
Ethernet Inevitably
“If you’re starting a project from scratch, you should go Ethernet all the way,” says John Lehman, sales engineer at Patti Engineering, a CSIA-certified system integrator in Auburn Hills, Mich. “However, the tough thing to remember about Ethernet is that an EtherNet/IP device and a Profinet device may have the same plug on the same wire, but they aren’t going to talk to each other. So, we use serial-to-Ethernet devices for converting and sending bar code data, for example, and gateways or single-board computers to talk to PLCs and SQL servers.
Patti recently helped an auto exhaust system manufacturer improve collection and tracing of gauge measurements. “The plant manager didn’t want PCs or Windows software on the factory floor, but their IT department did want PCs there to buffer the production process in case the main server ever went down,” says Lehman. “As a result, we installed ProSoft modules to talk directly from the PLCs to the databases.”
In another demonstration of Ethernet’s flexibility, Bombardier Transportation in Berlin reports that it’s delivering regional trains in Germany and the Netherlands with an onboard Ethernet Train Backbone (ETB) network for train-control data management (Figure 3). ETB will manage all of the train’s equipment at less cost and with more capabilities than the traditional Train Communication Network (TCN), and will employ Westermo Teleindustri AB’s Redfox railway switches. Though an Ethernet ring and TCN will coexist on the trains for now, Bombardier adds that ETB will fully replace TCN in two or three years. Besides integrating all of the train’s intelligent devices, ETB can determine what kind of coaches it’s using, what order they’re coupled and in which direction they’re running. TCN will be retained for train-wide communications.
Figure 3: All Aboard Ethernet
Bombardier is delivering regional trains in Germany and the Netherlands with Ethernet networks that manage all of the train’s onboard equipment and coexist with its Train Communication Network.
Source: Westermo
“This Ethernet Backbone carries all data types needed for control, security and passenger information, such as data from surveillance cameras, passenger announcements and information to control operation of the train and coaches, including doors, propulsion and lighting. Everything except signaling and Internet access will be managed through this Ethernet protocol,” says Klas Englund, Bombardier’s TCMS product manager.
IT and Engineering Integration
Ironically, the most useful tool in getting industrial networks to cooperate is still getting their plant-floor engineers and IT technicians to meet, talk, settle on goals and jointly plan and implement a better-coordinated network. Even now, many system integrators report an initial meeting with a user turns out to be the first time that its control and IT people have met each other.
Similar to many food and beverage manufacturers, Frito-Lay reports its industrial networks were mostly manual in the past and it still has some traditional remote I/O and Data Highway applications. “When we started to become more automated, we got into Modbus, Profibus and EtherNet/IP,” says Adnan Chaaban, Frito-Lay’s principal control and information systems engineer. “And as we began seeking better quality and downtime data, we knew that IT had to be a part of it.”
More recently, as part of an overall effort to bring its plant, enterprise and supply chain functions more closely together, Frito-Lay adds that it’s been organizing its control engineers and IT staffs for more effective collaboration. So far, they’ve cooperated on a packing and warehousing project that identified and implemented several more efficient procedures, saved several million dollars and increased the company’s operating flexibility.
“IT and engineering know they had to work together, but the challenge was they didn’t always speak the same language or approach problems the same way,” adds Rick Van Dyke, Frito-Lay’s group manager and chair of the Packaging Working Group for the OMAC Users Group. “For example, engineers are more concerned with solving functional problems, while IT worries more about overall plan and technical choices.”
Chaaban says he and his IT counterparts are now under the same roof and almost in the same cubicle, which enables them to talk about objectives and deliverable goals, such as how to improve their networks, probably by migrating to EtherNet/IP and using Modbus TCP/IP for linking to legacy equipment. “We’ve sat down with our engineering group and designed from scratch our required data flows,” he says. “It was important to talk and map out the data we needed, so we weren’t overwhelmed later.”
Once plant-floor engineers and IT professionals get talking, they can use some basic design tools jointly, says McBride. “A good AutoCAD network communications overview drawing is our fundamental tool. Often this is a D-size plot with all the protocols, baud rates, node addresses and other details included,” adds McBride. “Next, you need to plan your network carefully. Send across only the needed data. Don’t overload the networks with traffic that isn’t essential. Lay data out in files or structures that are compact.”
Gearing Up for Cooperation
Of course, there’s no single way to get industrial networks to cooperate, mainly because they come in so many types, configurations and applications. However, the collective input of many experts does produce a few common threads and points to a few methods that can help. Not surprisingly, they look a lot like the procedures for implementing a new network or renovating an existing one. The main snag is that many users will more often have to address the needs of several networks at once.
- Recruit network evaluation and improvement team from plant floor, IT and all other affected departments
- Inventory existing network types, connections, components, topology, other hardware and participating applications
- Examine present data types, transfer rates, packet sizes, cycle times, handshake methods, master-slave relationships and protocols
- Determine number and extent of inter-network links
- Try to identify any communication interference, conflicts, collisions or bottlenecks
- Evaluate how well existing network hardware and software helps meet overall business goals
- Draft new functions, requirements and specifications, if needed
- Decide which networking method best meets outstanding and expected needs
- Examine where new cross-network ties and interfaces might be most helpful
- Draft detailed plan describing all network features and links in one document
- Fully test contemplated network components and software before installation
- Configure new network components to meet unique parameters of existing infrastructure
- Implement new equipment and conduct regular follow-ups with team to check or update network performance
