How to Build an Industrial Network

So you want to build a network? Good luck and try not to panic. These days simply defining an industrial network is difficult, so it's no wonder the idea of building one may seem impossible. Traditional point-to-point analog, 4-20 mA, and other hardwired networks have been joined in the past decade by dozens of competing fieldbus protocols, hundreds of suppliers, and thousands of related ...

By Jim Montague, CONTROL ENGINEERING October 1, 2000

KEY WORDS

Networks and communications

Fieldbus

Devices-level networks

Sensor/actuator level networks

Local area networks

Sidebars: Network builders aid refiner expansion Building a functional network

So you want to build a network? Good luck and try not to panic. These days simply defining an industrial network is difficult, so it’s no wonder the idea of building one may seem impossible. Traditional point-to-point analog, 4-20 mA, and other hardwired networks have been joined in the past decade by dozens of competing fieldbus protocols, hundreds of suppliers, and thousands of related products—all claiming to be the best solution and all sounding eerily similar. Now, Ethernet-related protocols and the advent of embedded and wireless networking technologies are only making this situation noisier.

“This is why trying to build a network can be a lot like do-it-yourself brain surgery,” says Dick Caro, vp, ARC Advisory Group (Dedham, Mass.).

Bob Chappel, president, Advanced Integration Group (AIG, Lawrence, Pa.), a system integrator, explains, “Most networks look the same until you get down into them, and try to make them work and play together. Then you find out what works together and what doesn’t. For instance, we recently had a user with an OPC client server that did interface with a second vendor’s HMI using 100 tags, but then it really bogged down when it got up to 2,000 to 6,000 tags, and so we had to recreate the server client link. For awhile, we had two vendors pointing fingers at each other, and it was up to us to prove which was working and which had the problem.”

Due to this confusion, more engineers undoubtedly cling to the saying, “If it ain’t broke, don’t fix it,” than might, if changing didn’t seem so unapproachable. This is unfortunate, because many applications and companies desperately need the savings and efficiencies that new industrial networks can deliver.

“Not only can a fieldbus-based network save weeks or months in installation and debugging time, it also generates savings by allowing production to begin weeks earlier, and users should take this into account too,” says Mark Stremmel, president, Device Bus Integration Inc. (Harrisburg, Pa.), a system integrator.

Know thy application

If building the best network ends with installing the most appropriate system, then it obviously starts with finding that system. This is obvious on the surface, but many control and automation experts, system integrators, and suppliers report that users often don’t know enough about their applications and what they need to accomplish their goals. Some users even shop for capabilities their existing system already can perform.

Consequently, experts and integrators say users must thoroughly examine and account for their existing applications, capabilities, and operating environments. They must describe their existing network, determine its capabilities and operating parameters, and evaluate its ability to integrate with newer systems. This will help users define exactly what tasks they want their new network to accomplish —probably the most important step in building a network—because it’s the foundation for clear specifications, intelligent purchasing, beneficial vendor relationship, and finally securing the most efficient network for the least cost.

“We initially pull back from the technology, and try to determine our end-users’ business motivations. What are they trying to do? Increase production? Gather more data? Enhance security?” says Robert McKeel, operations vp, GE Cisco Industrial Networks (Charlottesville, Va.). “Then we see how particular technologies may help users find the performance they’re seeking, and look at which technology makes the most sense for that user.”

Even with simple networks, numerous variables must be considered. Layout type and concentration, wire distances, component shielding, types of information transmitted, data packet sizes, system speed, latency, I/O point concentrations, PLC methods, compatibility, hosts, master controllers, safety, personnel training, maintenance, and expansion needs in three to five years are just a few. Environmental factors—including electronic and electromagnetic interference, area electrical classification (i.e. Class 1, Div. 2), noise, vibration, hazardous substances, weather, available physical space and component crowding, and installation locations—must also be considered.

“The question is where is your existing network really feeling the pain? Because wherever you want to add functions, then that’s where you have to lay conduit and add cards to racks that are probably full already,” says Perry Sink, regional sales and marketing manager, Synergetics (Downers Grove, Ill.). “So they won’t be overwhelmed, many users prefer putting one toe in the water first.”

Instead of ripping out and replacing an entire network, for example, Mr. Sink says many users prefer to add an industrial network, perhaps Profibus, Foundation fieldbus, or DeviceNet, to one or two motor control centers with four nodes in an isolated plant area or lab. “This gives the user a chance to convince his manager that a fieldbus system won’t be a disaster,” he adds. “Many large networks start out this way.”

Renovation vs. replacement

Once all existing network aspects are identified, this list can be combined with functions the user wants the new or revamped network to perform. This will give a good indication of what new components are needed, and hopefully indicate—after costs are factored in—whether existing equipment should be renovated or replaced. This can be the most gut-wrenching decision network builders face because:

Renovation may save money, but it can fail to deliver some needed functions, and may increase incompatibility and integration problems between old and new components; and

Replacement can deliver more unified solutions, but its higher costs may outweigh overall benefits achieved.

Determining when renovation is no longer more cost effective than replacement is made even more difficult by unseen contributing factors. For example, renovation costs can quickly climb to replacement levels if users are forced to disturb too many existing wires, cables, connectors, and other equipment. Likewise, both replacement and renovation options are aided if there is enough space to leave old hardwiring alone.

Cost, availability, support

Because of installation and maintenance issues, the cost of buying a control system amounts to only 20% of the total cost of ownership over the 15-year lifecycle of a typical system, according to Dave Woll, enterprise integration vp, ARC Advisory Group. The only users lucky enough not to have to choose between renovation and replacement are those building new plants, now mostly in Asia and South America, says Mr. McKeel.

Explains Mr. Sink, “OEMs often know their material costs to the penny, for example, but many don’t know what percent of those costs go to network wiring materials and related labor. Once they do the math, they often realize why they should implement a fieldbus system. Big users do these evaluations, and smaller users need to do them too.”

For many users, however, an undeniable peace of mind comes with picking a well-supported network that seamlessly meshes with an existing installed base. Network selection may tie users to one vendor or set of vendors and limit access to some desired functions in the future. For example, two competing vendors may target the same network space, but one has more available functions. Users may not feel the need for these added functions now, but they should evaluate whether they’re likely to be needed in a few years, and consider securing them in the present for use in the future.

Several system integrators report that many users simply don’t have the time to learn about every fieldbus protocol, and so they’re willing to sacrifice some potential flexibility they probably won’t need in exchange for a “proprietary” solution support by one or a few vendors. Long-established solutions also tend to have more readily available product and support. Also, going with one solution or protocol means less training, which can be another significant cost.

To secure appropriate network components and work intelligently with vendors, several integrators say users can educate themselves and their employees, add checklists and benchmarks to specifications, and use integrators that specialize in those vendors. Many vendors also have test drive programs of their systems, and users should experience these when available. “Vendors will generally accept benchmarking requests and will try to meet specific requirements as part of their proposals,” adds AIG’s Mr. Chappel.

Ethernet, wireless emerging

All roads are beginning to lead to Ethernet, even of not everyone is walking them yet. Though other networking methods—including physical media and fieldbus protocols—may prosper and survive for decades—just as pneumatic, hardwire, and PLC controls persevere today—much of the organic growth in control and networking will likely occur among Ethernet-based applications.

“Ethernet is becoming the de facto standard in our industry. Everyone seems to be using 100 base T connections. My engineering staff is standardizing on it,” says Mr. Chappel. “In the past six months, everyone had also started talking about connecting through web pages for monitoring and non-critical applications.”

However, while a traditional network may be able to display data via the Internet data, it likely has to pull that data back into a database, and then serve it to a web page. A purer Ethernet solution may use an embedded web server to deliver information directly, which is reportedly faster than going through a database. Again, users must investigate these differences relative to their own applications and apply the most appropriate solution.

Ethernet will likely replace many control system methodologies, but it won’t replace the need for users and integrators to perform thorough systems evaluations, ask intelligent questions, develop precise specifications, and require that suppliers follow them. “If you truly understand an application, that comprehension will lead you to the right decisions, and help narrow your choices when building a network,” says Synergetics’ Mr. Sink. “Then you can take a specific list of requirements to vendors, cut through the jargon, and focus on proven components.”

Network builders aid refiner expansion

A team from GE Cisco Industrial Networks (Charlottesville, Va.) recently analyzed Cenex Harvest States’ Montana-based cooperative oil refinery network, especially one 300-mile pipeline, to help the company increase capacity and provide scalability for future growth. Cenex needed to reduce traffic and improve bandwidth on its Ethernet fiber-optic pipeline network.

The team found the existing network was based on one flat-collision domain, which spread traffic among all devices, and recommended migrating to a switched network architecture, which separated Cenex’s supervisory control and data acquisition and corporate networks onto distinct virtual local area networks, allowing communication where required.

This solution used Cenex’s existing fiber backbone, but replaced standard repeater devices with smart network switches to create individual collision domains, limit traffic, and enable Cenex’s subsequent 70% increase in capacity.

Building a functional network

After required features are determined, network component selection should follow several basic steps, according to Nick Jones, product manager, SST (Waterloo, Ontario, Canada), a division of Woodhead Connectivity. Based on individual requirements, these steps include:

Select a control architecture—either centralized, semi-distributed, or highly distributed.

Choose a communication strategy—such as sOtrobe/poll I/O communications, cyclic I/O, change-of-state I/O, or explicit messaging.

Select devices—evaluate that they provide sufficient performance, which is a combination of I/O update interval and control logic performance; make sure they support the network’s baud rate, communication strategy, and a subset of available communication types; check that they’ve passed any applicable protocol conformance tests; and ensure they comply with standard device profiles.

Design networking wiring—use appropriate network layout or topology—such as trunkline/dropline, ring, tree, or star—with allowable distances governed by maximum baud rate and power requirements appropriate to the network.

Configuring network power—evaluate and implement appropriate range; make sure voltage drops don’t exceed requirements and that current doesn’t exceed cable/connector limits; remember to follow maximum current inrush specifications for each device; and use multiple power supplies with care.

Grounding—connect dc power supply common wire and the shield to a low-impedance ground at the power supply. If multiple power supplies are used, the ground connection must be made at only one supply, preferably the one nearest to the network’s center. All splices and taps in the network must connect the shield, as well as the signal and power lines.

Testing—several can be performed with all devices installed and power supplies turned on, though they should not be performed while the systems is operating (i.e. no communication). Common problems can be found before communication problems occur by testing network termination and communication wires, grounding, network power, station addresses and baud rate settings.

Diagnose faults—faulty devices, opens and shorts in network wiring, electrical interference, and signal distortion or attenuation can be identified using several methods. Some are found by disconnecting part of the network and watching where the fault goes. Because your brain is the best diagnostic tool, think like a detective. Write down symptoms with as much detail as possible. Ask yourself questions, such as “Do intermittent problems occur when other unrelated equipment is in use?” Look for patterns in the symptoms: Do some nodes communicate correctly? What do they have in common? What is the difference between the functioning nodes and the others? Consider factors, such as proximity to the power supply, terminator, or scanner. Even if you can’t find the problem, collected data may be valuable when other assistance is enlisted.