Interested in linking to "The One Network"?
You may use the Headline, Deck, Byline and URL of this article on your Web site. To link to this article, select and copy the HTML code below and paste it on your own Web site.
Coordination by Profinet
Meanwhile, Foundation fieldbus is a popular choice, even in Europe. At its meeting in Antwerp this year, FF touted its process industry products. However, most Foundation fieldbus applications are limited to H1, its two-wire network with the same physical layer as Profibus PA. While high-speed Ethernet has been part of FF’s specifications for years, commercial implementations of HSE are still relatively few.
What was originally H2 (hunk two) back in the days of SP50 hasn’t caught on, mainly because most DCS suppliers that dominate the large process industries—Honeywell, Invensys, Yokogawa, Emerson—chose to implement a proprietary network, with all current offerings based on Ethernet. And end users “voted” with their dollars, reinforcing impressions that delivering H1 is sufficient. HSE capability hasn’t been the differentiator that H1 has been. Asked if support for HSE would ever be a differentiator for system choice, one user says, “For internal DCS communications, neither pro nor con. HSE seems to be a dead letter. If they pushed everything to OPC, then I might get excited, assuming they had tools to keep servers and clients synchronized.”
This choice of system architecture harkens back to the heritage of these systems. Unlike PLCs, a DCS was traditionally sold as a “system.” Unlike the users who primarily used PLC’s for control, the industries that wanted a DCS were shopping for a solution, even when this slogan wasn’t part of the marketing vernacular.
Walt Driedger of Colt Engineering in Calgary, Alberta, Canada, says that, “When you buy a PLC, you’re buying the ‘engine,’ and so you may be on your own to provide operator interface, historian, etc. When you buy a DCS, you’re buying the whole vehicle.” While many PLC vendors raked together some standard operator interface, historian, alarming and reporting packages that allow them to be called a DCS, they are rarely found on the bid list for a large process plant project. Yokogawa likes to say, “We have reliability in our DNA.” Users in the large process industries have a sense—or a prejudice—about who has “reliability in their DNA,” and are very reluctant to “step out” unless a system has been vetted by their peers.
These heritage DCS suppliers have always controlled the system-level network, and still see it as a critical to their offer. Charlie Piper, Invensys’ senior development program manager, says, “The system network for the process automation system is a vital part of our supply scope. It needs to be extremely robust. Protection against single points of failure isn’t enough. I/A Series mesh network can tolerate multiple faults in different locations, while still communicating among all network equipment, and it contains patented technology unavailable commercially to do so. The system network must tie together, not only DCS controllers, but also safety and supervisory controllers. Its performance and peer-to-peer capabilities must be flawless. The system network also needs scalability. We have facilities that connect 50,000 or more instruments and field devices.”
And as Microsoft Windows security patches, bug fixes, and hardware changes are released, classic DCS vendors are expected to do exhaustive tests to ensure their installed base doesn’t have a hiccup.
Some people grouse that proprietary networks are maintained to “lock in” customers, and with respect to safety systems, they may have a point. The effort and expense to connect a “foreign” SIL-capable logic solver may compel many to default to the DCS supplier’s standard, and nearly all of the aforementioned vendors have bonafide SIL-3 logic solvers. However, large system users may think twice before connecting a SIL-capable system to any open-protocol control network, especially with growing cybersecurity worries.
As you read this issue of Control, you’ll no doubt notice many ads offering Ethernet TCP/IP connectivity for many flavors of I/O. Whether you use Modbus TCP/IP, industrial Ethernet, Profinet or EtherNet/IP, you can buy inexpensive I/O to ride on it, along with converters for RS-232, RS-485, Modbus, AS-i or wireless.
However, this doesn’t mean you can hook a Cat-6 cable to a spare RG45 jack on your host system’s network switch and start reading and writing to the I/O. Maybe you’re brave enough if your system is small and lightly loaded, but how many of us would risk unknown network traffic from a device that wasn’t explicitly approved by our host vendor? Early wireless pioneers sent measurements to the World Wide Web, and read them down into their historians because no DCS engineer at these beta sites trusted their proposed system interconnection. Hodson adds, “Interconnecting via TCP/IP over Ethernet assures arrivals of messages, but this doesn’t mean they’re understood by the communicating parties. As long as there are different application layers and application object models for Foundation fieldbus, Profibus, DeviceNet/ControlNet, HART and the others, there won’t be meaningful interconnections.”
Now, Profibus, Foundation fieldbus and HART have been playing well together for a few years and cooperating via electronic device description languge (EDDL) and on the new Wireless HART interface—the backbone that brings data into the host. PTO and FF also are offering to work on the same service for the ISA-100 wireless standard, if it emerges.
ControlGlobal.com is exclusively dedicated to the global process automation market. We report on developing industry trends, illustrate successful industry applications, and update the basic skills and knowledge base that provide the profession's foundation.