By Bob Waterbury, Senior Editor
Proprietary systems no longer rule. OEMs are using off-the-shelf personal computers, commercial technology, and standards-based software to devise best-in-class solutions to automation problems. They are using open systems to maximize functionality, achieve cost-effective control, simplify integration, and reduce operating and maintenance costs.
Success stories about PC-based open systems are becoming common throughout the machining, metalworking, packaging, and factory automation industries. Recognizing both the immediate operational and future migration benefits, end users are specifying more PC-based open systems in OEM and system integrator contracts.
Anything seemingly that good must also have drawbacks. Indeed, when selecting hardware from one vendor, software from a second, and cabling and networking devices from a third, there are bound to be incompatibilities or inconsistencies.
Sometimes these problems are not evident until it is too latewhen a major production problem arises. "The beauty of open systems is that they drive costs down while they increase functionality," says Dave Riling, advanced technologies manager, Wright Industries, Nashville, Tenn., a builder of automated assembly and robotic systems for industries that include semiconductors, electronics, and chemicals. "But when things go wrong with multi-vendor system solutions, support can be a nightmare. Judging from the amount of finger pointing that can occur when problems arise, you might think you're dealing with Curly, Larry, and Moe."
Open-System Standards Abound
An open-system application should be able to communicate and interoperate freely in a heterogeneous environment. In addition, an application and its databases should be capable of transport and migration from one version to another without losing data or functionality.
Unfortunately, there is no universally accepted definition of an open system. "An open system may be defined from the standpoint of what is commercially accepted, something based on a national or international organization standard, a consortium-based standard, a de facto standard, or even a licensing standard," says Dave Smith, network promoter and consultant, Siemens Energy and Automation, Norcross, Ga.
Official standards are generally developed and voted on by an organizational membershipusually an engineering bodysuch as IEEE, OSI, or ISA. Consortium-developed standards are more limited in scope and/or geography, and normally represent special supplier interests. DeviceNet and Profibus publish accepted standards that fall into this category. De facto standards are commercial productssuch as Microsoft Windowsthat have become common in their selection and use throughout a specific marketplace. Laws, such as those passed by the Federal Communications Commission, also define standards that are usually rigid in their application. And finally, licensing standards for use of a particular technology are generally controlled and granted by one source.
"In any open system, actual protocol stack testing is both necessary and foundational to the device testing that takes place later," says Smith. "Don't assume this has been done; ask for the results.
Most industry participants say the definition of an open system, what it conforms to, and the certification testing process are critical to open system implementation. "There may also be different degrees or subsets of conformance as in Ethernet and the various protocol stacks that are used in conjunction with it, says Horst Kolbert, network products marketing, Siemens E & A. For instance, TCP/IP is often used with Ethernet, but Fieldbus, Profibus, and other protocols may sit on top of it as well."
An open system provides freedom of choice. Ideally, it allows OEMs and integrators to buy hardware or software from a vendor of their choice, and still get standardized functionality and competitive pricing. Once developed, the logic to control the hardware should be the same from one supplier to another. And data should be capable of being shared seamlessly among the various networked devices.
Interoperable vs. Interchangeable
Most suppliers say that their products conform to a particular standard, but what does that really mean? "Major customers such as General Motors buy only products that have been conformance tested," says Steve Biegacki, vice president of commercial marketing, Rockwell Automation. "The average customer, however, is simply buying the best of breed in a mix-and-match environment. This is both an opportunity and a problem. The two main issues that must be sorted out involve interoperability and interchangeability."
Systems that conform to a particular standard can be expected to communicate with one another. "This means they should be interoperable," says Bob Rucinski, manager of the production integration team, GE Fanuc, Charlottesville, Va. But you can't even assume that. For example, some Profibus devices may support Intel processors, and others may support Motorola processors. Somehow, those bits have to be swapped for proper operation. In addition, suppliers may implement only a portion of an open system protocol, limiting its compatibility with other products that conform to the full standard protocol. So, even though product validation processes may be very thorough, they still may remove only about 85% of the bugs," adds Rucinski.
Interchangeability is perhaps even more difficult to assure in a mix-and-match open system environment. Although the protocols are identical and the processors totally compatible, suppliers are prone to add unique features that distinguish their product from others that conform to a particular standard. "For example, two photoelectric eyes may conform in all essential details to a certain standard. However, if one has a built-in counting/timing function and the other does not, they cannot be used interchangeably because of their functional differences," says Biegacki.