Multiple choices

Gene Chen, product manager for Honeywell’s wireless network, adds, “As with most emerging technologies, today’s market offers proprietary, wireless-enabled solutions that tactically solve industrial business needs, but might not meet requirements for the future. Key implementation issues that must be addressed include handling multiple types of devices from just a few to a thousand, operating in a noisy RF environment, sending data reliably, good device power management, and solid, simple security. Many industrial facilities already are deploying wireless networks for targeted requirements, but they also need to consider the future. For example, functionality, reliability, security, power management, scalability, sensor support, control loop support, actuator support, and 802.11 WiFi support all play a role in future plant expansion. Wireless networks that don’t address each area may not fit long-term strategic use.”

OPC’s New Worlds
Not content to rest on its interoperability progress, the OPC Foundation plans to follow the 2006 release of its OPC Unified Architecture (OPC-UA) with an even more far-reaching project early in 2007. Tom Burke, OPC Foundation’s president, says the organization has been working with Microsoft and Sun Microsystems to develop OPC-UA Universal Discovery protocol, and plans to release it in the next three to four months. Based on web services, Universal Plug-and-Play, and Universal Device Discovery Interface concepts, this new discovery protocol is expected improve OPC’s plug-and-play functions beyond its connecting capabilities.

“This isn’t just connecting. This is connecting and being able to find out much more about the device you’re connected to,” says Burke. “Many end-users can’t communicate with and understand their existing components and systems. This will allow them to find out about all the systems out there, and do discoveries independent of the system they’re running on. This means users can find out what’s on all the computers they’re connected to, and scroll down through a list of all their programs. So, when you plug a PLC in through this protocol, it will automatically provide the information other devices will need. For example, if you have a sensor on a door, you’ll not only be able to know when it’s open or closed, but can find out who opened it and get their complete authorization.”

IT Taking Over?
One slightly ominous trend is that some IT departments are becoming more responsible for process controls and automation. Where most IT staffs traditionally were responsible for specific servers, PCs, and corporate intranets, the influence and jurisdiction of some appears to be expanding as controls mix with Internet-based technologies and as corporate-level users want to see more real-time manufacturing data. In fact, because IT ends up controlling the specs for PCs and PC-based controls, some controls engineers are ending up working for their IT departments.

“There can be problems when IT takes over because they might think it’s okay to take down a network at midnight, even though it’s not okay because an application is running,” explains Hoffman. “IT also might send a virus update to plant-floor devices that don’t need them, even though telling a machine to do a virus scan could lock it up. Unnecessary shutdowns like this have been increasing over the past three or four years. A lot of IT people now are getting those 3 a.m. calls, and regret taking over plant-floor systems.” 

Doug Brenner, principal engineer at Superior Controls, a system integrator in Plaistow, N.H., adds that, “IT traditionally owns the corporate Ethernet network. In the past we typically installed a separate network for controls. Now companies can have one physical network, and use port filtering to allow ports on a switch to be grouped into separate logical networks. So, for example, there’s a separate logical network that supports PLC communications to SCADA nodes. In our experience, any critical I/O communication such as Ethernet/IP still is separate. It’s the operator interface and monitoring network that can now be reliably integrated into the corporate network.”

Likewise, IT managers usually own the network, server room, corporate standard servers, and desktops. Because IT also owns information processing, it becomes more involved as increasing value is put on information and integration, even if IT doesn’t own factory automation.

“Then all the MES stuff is integration between ERP and process automation, which is a natural for IT,” adds Brenner. “A confluence of 21 CFR Part 11, Sarbanes Oxley, and similar types of requirements beg for centralized data management. You even could argue that 21 CFR Part 11 really is all about IT requirements for process automation.” In addition, some of Superior’s customers can view read-only HMI screens anywhere, anytime over a VPN. Network filtering is used to restrict access to the servers from which changes can be made.

“In places where IT doesn’t own process automation, relationships with IT are either very cooperative or still are evolving,” Brenner says. “We work with one large company where the IT infrastructure is good and the network is solid, the IT people are very service oriented, and we work closely with an Oracle DBA. At another large company, where the relationship is still evolving, we’re installing software, but one thing that makes it difficult is that we don’t have control over the network and SQL Server database, and IT support isn’t readily available. There are a lot of projects that are easier and more reasonable to do when a solid network is already in place.

One positive change resulting from using corporate networks and IT involvement, says Brenner, is the ability to use a corporate domain user name and password for security. In the past they had sites with system-specific individual user names and passwords.

If you want to build an industrial network, there are a few basic questions you need to ask yourself before you get started. These can focus your search, and help you implement the most appropriate network for your application.

• What’s your primary reason for  establishing or renovating your industrial network? Define what you need to accomplish.
• What are your topology requirements? What physical dimension and layout does your network need to have?
• How small can you go? Can you experiment with a smaller network first and grow as you go? Or do you need a large network and immediate help from a system integrator? 
• What are the speed and data-size requirements of your information application? How often do you need to scan your system? Do you need small data packets delivered quickly, or does your application need to process larger data chunks slowly?
• How are you going to secure and provide power? Do you need to run more wiring? Can you use batteries or even Power over Ethernet (PoE)? 
• Do you need a hardwired, 4-20 mA, point-to-point network, or can you use a twisted-pair fieldbus, Ethernet flavor, wireless, or Internet-based strategy?
• Does your application need a combination of networks? It might be useful to ask yourself the first question again here.
• What about connector uniformity and other accompanying hardware issues? Is the chosen configuration simple and reusable? What support and system integration services are available locally, and how soon can they get here if needed?