With all the hoopla around the Internet, there is a growing belief among many that the World Wide Web can take the place of almost any network. However, at least one major human-machine interface (HMI) software supplier, Rockwell Automation, has begun cautioning HMI users to look hard before putting all their eggs in that Web basket.
"If all you need to do is to look at a snapshot of historic information, then yes, the Web can do that. But if you need real-time plant floor monitoring and control, if you need to know immediately when some aspect of your system changes, if you need an alarm system that will notify you the instant something goes wrong, the Web is not yet able to provide that solution," Rockwell Automation said in a white paper expected to soon be released.
Rockwell Automation acknowledged the Web's benefits, especially cost savings. For example, the Internet requires only nominal client administration—often just a browser and a network connection; enables distribution of business logic to servers anywhere on the Internet; and allows access to data from any computer with an Internet connection, anywhere in the world. The Web also pushes resources to the server side, resulting in low-cost ("thin") clients.
Because most large integrated automation applications require many HMI stations connected to a few programmable controllers and databases, it's logical to make HMI stations browser-based and connect them through the Internet, right?
Wrong, Rockwell Automation warned. That's because current Internet and Web technologies cannot yet provide what most existing HMI users need: high data rates, high animation capability, and subsecond screen changes.
"Unless and until technology changes dramatically, Web-based solutions will only satisfy a portion of the current market for HMI: those whose applications can tolerate low bandwidth and duty cycle, moderate to low data transfer, and primitive graphical animation capability," the white paper cautioned. "For the existing customer base, most of which is used to rich, responsive animation, high data throughput, and close to real-time screen control, Internet and Web technologies, when used alone for HMI architectures, will not satisfy their requirements."
Standardized Web protocols are the problem. The International Organization for Standardization's seven-layer open systems interconnect standard dictates that hypertext transport protocol (HTTP) is the language of the Web.
However, HTTP is inherently a one-way protocol. HTTP's principal capability is a command called "GET." When a user running an application in a Web browser requests a page, the system launches the HTTP GET command. It contacts the appropriate Web server. The server accesses the requested page and sends it back to the browser. The user then views this page. However, the page is static, and the data on it doesn't change.
If the user wants a new page of information, the system must fire off the HTTP GET command again and again and again—at rates probably on the order of one per second to even attempt to mimic current HMI systems' animation capabilities. Basic HTTP and hyptertext markup language (HTML) were never really designed for page animation.
Extensible markup language (XML) improves the situation only marginally for high-throughput applications because, Rockwell Automation said, there are at least two problems: First, "XML requests" still depend on HTTP GET. Second, XML markup is done in text format. As formats for data transfers go, it is one of the "fattest" yet invented. Each time XML data is transported, network overhead is spent transporting both the true data and the XML markup formatting.
"Again, this overhead may be completely adequate for low-bandwidth HMI applications, but the overhead and the polling certainly present an unfortunate upper bound for high animation rate, Web-based HMI," cautioned Daryl Walther, product marketing manager for Rockwell Software's Visualization business unit.
"This limitation of XML is well known to the OPC Foundation," added Walther. Rockwell Software played a key role developing the Microsoft-based OPC technology, now widely accepted by manufacturing industries.
"The OPC technical committee on XML has identified that using XML on top of HTTP will limit the throughput, for all the reasons stated earlier, and so the technical committee is looking into the possibility of eliminating the need for and use of HTTP and other protocols," Walther said.
XML's throughput limits on HTTP also applies to a more recent Internet protocol, simple object access protocol (SOAP), which sits on top of HTTP3. Soap uses XML to provide client applications and their servers with an object-oriented abstraction. SOAP's "polling strategy may serve well in low-bandwidth requirement vertical markets and for the general-use Web, but it falls short in performance for high-end HMI and real-time data acquisition," Walther added.
"This inadequacy of the SOAP protocol is truly disappointing for another major reason: The next major technology initiative from Microsoft, called .NET, positions SOAP as the principal remote messaging technology. Microsoft and .NET are not currently meeting the manufacturing and automation markets' higher performance requirements," noted the Rockwell Automation white paper.
HMI users lack political clout with the Internet and Web software community because "HMI users simply do not command a large enough market share to force Internet technology to conform to their needs," it added.
"High-throughput tasks, particularly data acquisition and alarm annunciation, will not perform well enough in a polling environment. For these, an interrupt, or event-driven acquisition protocol, is needed. Event-driven protocols will be required even if HMI continues to use HTTP for low-bandwidth features and tasks," the white paper continued.
In an event-driven protocol, rather than polling a server to get new data, a client connects to the server and "subscribes" to the data of interest. Whenever data on the server changes, it will "publish" or "advise" that data to the subscribed clients, showing only the data a client is interested in rather than all the data, as is the case in polling.
"Two segments of the HMI market will emerge, and it is very important that users understand what segment they belong to prior to committing to a solution," the white paper said. "There will be those who find that the standard existing Web protocols [Rockwell Software RSView32 Web Server, for example] provide an adequate solution for their needs. These users will not require high throughput or close to real-time animation.
"The rest of the HMI market will not find this low-throughput solution acceptable. . . . Other protocols that support high-throughput, event-driven strategies will be required to complete the promise of the next generation of high-performance HMI. These protocols are available."