Las Vegas is no stranger to high-stakes games, but arguably one of the highest-stakes contests of recent times occurred when the OMAC Packaging Workgroup (OPW) and the OPC Foundation teamed up with technology suppliers Acumence, B&R, Beckhoff, Elau, GE Fanuc, Iconics, Kepware, Siemens and Wago for an integrated packaging line demonstration during PackExpo 2007 Oct. 15-18.
Years of effort and a fortune in development costs were on the line as the technology vendors who have backed OMAC and OPC’s efforts sought to show that packaging-line functions such as control, human-machine interface (HMI), manufacturing execution systems (MES) and enterprise resource planning (ERP) could be linked using the OPW Connect-and-Pack guidelines employing OPC (a communications standard) over Ethernet. It was, by all accounts, successful, though interpretations as to the degree of success vary.
“It was a resounding success,” says David Bauman, technical director for the Open Modular Architecture Control, or OMAC, Users Group. “It was basically very easy to take any controller in the demo and connect to any HMI or MES system in the booth just by connecting to an Ethernet switch for the physical connection and configuring OPC so the client could talk to a server.” He stresses that each of those demo applications was independently built and there was very little testing done ahead of time.
One of the knocks against OPC, though, is that it can be cumbersome to implement, with non-Windows-based controllers typically needing an extra personal computer (PC) acting as a converter from a proprietary protocol to OPC. There is thus some added cost, complexity and time—all things the Connect-and-Pack guidelines are intended to minimize. Bauman thinks those objections are overstated.
“Certainly, control vendors have to provide an OPC server for their controller, and then that OPC server has to be hosted somewhere. But Kepware had several different OPC servers hosted on their PC, and in a typical application, I think that’s the way you would want to have it configured, with a single PC providing OPC server-type connectivity to whatever controllers were employed.”
New rules
That’s with the traditional Distributed Component Object Model, or DCOM-type OPC. In the eyes of people such as Stefan Hoppe, product manager for Burnsville, Minn.-based Beckhoff Automation LLC, the recently released OPC Unified Architecture (OPC-UA) changes the game. “With OPC-UA, the protocol is directly TCP-enabled (for transmission control protocol). The UA stack is independent from operating systems and programming languages, so UA can be easily integrated into very small, embedded devices. This is a great opportunity for platform-neutral connectivity independent of operating systems, hardware and the like.”
In addition, because OPC-UA integrates all previous OPC standards, there will no longer be a need for separate OPC interfaces for data access, alarms and events, historical data and the like. They can be accessed through a single OPC framework that will also allow these separate functions to talk to each other.
Along with the myriad potential benefits of greater connectivity, Hoppe sees OPC-UA benefiting end-users in other ways as well. For example, they will save money because there is no need for an extra OPC gateway PC. For Tracy Lenz, product support manager for Wago, based in Germantown, Wis., this effectively “takes a link out of the chain,” a degree of simplification that will save end-users time and cash through reduced time for software installation and configuration.
Bauman notes, “With OPC-UA, some controller vendors will be embedding the OPC server in the controller rather than have it hosted on a PC, so they will be able to do that if they wish. But I think a possibly even bigger issue that OPC-UA addresses is security.”
Hoppe expands on that notion. “Today, the security issues are delegated to information technology (IT) departments. They have to take care of secure TCP channels. But security is included in the official OPC-UA stack (which is available royalty-free to OPC members). Users have the option to enable or disable the use of security.”
Disable the security? Hoppe explains that in a local network, for instance, the user might be interested in high-end performance connections without security. However, for most applications, users will welcome this greater degree of security. “So there will be no more need to move the issue to the IT departments; instead, UA will guaranty security between end points: the UA-Client and the UA-server.”
“Security is a key concern here because with OPC-UA, we are linking technology and functions that cross the corporate firewall,” says Tom Burke, president of the OPC Foundation. “We are aggressively working on a complete certification program to make sure that the products that are based on OPC-UA are of the highest quality and consistently exceed the end-user expectations for secure reliable interoperability.”
Jump-starting innovation
“In addition to our certification testing, we will be providing OPC members with sample code so they can jump-start their OPC-UA product development,” says Rashesh Mody, vice president, HMI and SCADA Business Group, at Wonderware, in Lake Forest, Calif., who also serves as chief architect for OPC. This, he says, is an unusual step for OPC. But he notes that people sometimes interpret specifications differently, so OPC is going a step beyond the typical specification rollout procedure to help ensure that its associated vendors are all on the same page and working together.
Mody says that the members of the OPC-UA early adopter group, roughly 20 vendors in all, will introduce a significant number of UA products in the next 12 to 18 months, with many others from a variety of vendors to follow.
Along with the obvious advantages of plant floor-to-enterprise connectivity and heightened security, there are other interesting new wrinkles to OPC-UA as well. Bauman again: “One of the major potential benefits of OPC-UA is the creation of super tags. This means that when the user connects to a controller, he won’t have to configure all of the PackTags to OPC; rather, there is the potential to create a super-tag structure that contains all the desired tags. Therefore, he can simply command the system to connect to PackTags, and all the information in those tags will be made available through that structure.
"That will make achieving connectivity in the future a lot easier than it is today.”
Tag configuration is obviously a front-brain issue for someone such as Bauman, who through his work with OMAC has been intimately involved with the creation and promotion of the PackTags initiative. OPC’s Burke stresses that working with organizations such as OMAC is a central part of OPC’s approach to developing specifications and to its strategy for getting those specifications adopted by users. Other industry groups or initiatives with which OPC has forged links include the ISA SP88 committee (covering the Instrumentation, Systems and Automation Society’s Batch Control standard), the ISA SP95 committee (for ISA’s Enterprise/Control Integration standard), MIMOSA (Machinery Information Management Open Systems Alliance) and FDI (future device integration).
Burke adds, “You measure success by the level of adoption, not by the elegance of your specification, so that’s why we’re trying to work closely with organizations and vendors to make sure we’re developing the right technology and specifications that fit with user needs. The last thing that anybody wants is to develop an academic specification that isn’t suited to people’s real-world needs.” He feels this approach not only results in a better product, but it also speeds implementation. “What better way to have vendors adopt the technology than to have them help develop it?”
Aiding adoption of OPC-UA is the fact that the organization and its supporters have developed what he calls a “rock-solid migration plan” from existing OPC applications to OPC-UA. He refers to it as an “adaptor,” as it takes existing OPC product and allows it to become Web Services-enabled, or UA-compatible. “OPC vendors will distribute that adaptor component as part of their products. So anyone who develops any OPC-UA product will distribute this. It’s essentially an open source product.”
“This is a very important feature,” adds Mody, “since there are literally millions of earlier OPC installations out there.” The end-user-driven aspect of OPC’s strategy calls to mind one of Burke’s favorite analogies—the consumer electronics market.
“The world has spoken with respect to consumer electronics,” Burke notes. What it is has said is that it wants “reliable multi-vendor interoperability” in its products. End-users, he claims, want to know why some vendors act as if interoperability is only a dream of the distant future—like an industrial version of Star Trek—and many vendors insist that if the end-user wants interoperability, the end-user will have to pay extra for interoperability.
Imagine, though, if you had to pay a premium to get your consumer electronics products to work together, or else buy all of your products from a single company. “Would you do it?” Burke asks. He is quite confident the answer is no. So why are automation buyers forced to do just that is Burke’s question.
The challenge
For backers of both the Connect-and-Pack guidelines and OPC-UA, the watchword for the days ahead is education. “Interest in OPC-UA from both vendors and the end-user community is very high right now,” claims Mody. “The challenge now is to keep the ball rolling through education and success stories like the recent OMAC demo. That was a very powerful step in getting the word out.”
“Our focus in the next year is going to be more on training and education, basically trying to get the word out,” says Bauman. “We think the basic functionality is there, but what we really need is to continue to press for adoption. Most technology providers are pretty well on board with us, but the task now is to gain adoption from machine builders and users. That’s our challenge.”
It’s not a simple task, because early adoption implies an initial expense—never an easy sell despite the promise of significant cost savings down the road. Still, as Markus Sandhofer, member of the OMAC executive committee and sales manager for B&R Automation, in Roswell, Ga., points out, information has power. “The European companies are very open to new technology and new standards, but so far, they have been a bit skeptical of the OMAC initiatives, since they see them as a strictly ‘Made in the U.S.’ affair. Lately, though, the European machine builders have started to become interested in OMAC. Why? Because their American end-users have started to talk to them about OMAC and about PackML. As they learn more about it, there is clearly a greater possibility that they will embrace it. Still, everything depends on specifications from the end-users.”
● For more information, search keywords “OMAC” and “OPC-UA” at www.automationworld.com.
