The lure of low costs is leading manufacturers of all stripes to look at personal computers in a new light. The versatile PC is now viewed as a platform for new generations of industrial controls. The controls will be less expensive, so the thinking goes, because they will be based on openly published standards. Such standards will keep costs down by encouraging competition among numerous vendors.
This vision of the industrial future recently brought together some 300 attendees to a meeting in Paris called the PC & Automation Conference. PC & A is run by the international Interbus Clubs, to which belong some 400 vendors and users of open controls. Their view is that the factory of the future will largely be run by hardware and software that have already emerged as de facto industrial standards: MS Windows CE as the operating system that orchestrates the software, Interbus as the communication standard for controllers and input/output devices, and controllers that outwardly might resemble programmable logic controllers, but internally have an architecture of an industrialized PC.
Meanwhile, software vendors are vying to provide higher-level factory control and coordination functions. The general plan is to build specialized industrial applications upon widely used packages such as MS Back- Office, and on operating systems that include Unix and Windows NT.
Of course, neither Unix nor Windows is real time. To handle motion-control events that unfold every few milliseconds, third-party partners continue to develop real-time extensions for these operating systems, apparently with the blessing of the Redmond, Wash., software giant. A Microsoft spokesperson says the company itself has no intention of fielding a real-time version of Windows NT.
The attraction of Interbus (once referred to as Interbus-S) as a control standard is twofold. First, multiple vendors offer products adhering to the standard, and these range from simple I/O to intelligent motion control modules and operator terminals. Second, Interbus can be more reliable and efficient than alternative approaches, say its adherents. Though they run at a relatively low 500 kpbs, Interbus networks provide a greater data throughput than some that use a higher clock rate. This lower speed lessens their susceptibility to electrical noise.
Interbus is a total summation frame protocol that is known for being completely synchronous and deterministic, effective over networks encompassing large distances of up to eight miles. Moreover, faults in Interbus networks are easily diagnosed, particularly during installation, say vendors.
“If someone runs over an Interbus network cable with a forklift, the affected modules send back a message to the master controller indicating the exact location of the problem, based on the transmission errors,” explains Mark Knebusch, Interbus group director at Phoenix Contact Inc. “You can go directly to the segment between two modules and fix the problem. And that applies even for the intermittent problems of electrical noise. Standard diagnostic software can time stamp incidents of trouble. You can then correlate this with some event in the plant such as the switching on of a welding station.”
This deterministic, diagnostic process contrasts sharply with the procedure for finding shorts or opens in multidrop networks. “The line impedances of other multidrop networks tend to vary widely, so technicians typically are forced to do a lot of trial-and-error checking with expensive line analyzers,” continues Knebusch.
There has, however, been a major misconception about Interbus: That one bad module could take down the entire Interbus network. This arises because all nodes handle all messages in the total summation frame protocol as used by Interbus.
However, vendors have addressed this difficulty with controllers that can subsegment a network and keep it working if any given module goes off-line. When a remote bus node dies or bus lines become open or shorted, nodes physically before and after the fault automatically reconfigure the network and continue to operate.
Also not widely known is that bus master modules are available from vendors in addition to Phoenix Contact, the original developer of the Interbus protocol. That firm now has a daughtercard that lets any suitably equipped controller provide Interbus master functions.
One indication of the impetus for open controls comes from the auto industry. Four years ago the Big Three published a set of guidelines that explained how industrial controllers for auto plants should be configured. The concepts in this document made sense not only to automakers, but also to aerospace manufacturers. Representatives from the two groups last year formed the Open Modular Architecture Controller User Group to promote the concept of open controls.
One goal of OMAC is to set up a repository of open architecture control requirements and operating experience. Another is to speed development of application programming interfaces for motion and machining operations that controls vendors can use.
The attraction of OMAC specs includes less initial system cost and less effort needed to make equipment from different vendors work together. They also define the flexible and modular controllers for the manufacturing strategy now driving the auto industry. This strategy combines reconfigurable machining operations with communications facilities.
Open, modular controllers are expected to blur the distinction between CNC and discrete applications usually handled by PLCs. Adherents also foresee that users themselves will largely add to or upgrade controllers without relying on outside vendors. Ditto for troubleshooting and maintenance.
The modularity concept of OMAC lets one module replace another, even if the replacement isn’t identical. An OMAC controller can also be scaled up or down by adding, removing, or juggling modules. For example, unplugging motion control and network interface modules from an OMAC controller would theoretically leave something able to handle low-end discrete control. Scaling the same controller up for sensor- adaptive-controlled machining would be as straightforward as installing the hardware and software building blocks.
OMAC supporters realize that the task likely to require the most development work is the writing of API software. One reason is that it will entail agreements among component suppliers to make such interchanges possible.
There is no question, though, that manufacturers still have qualms about hooking up controls to a PC. Reliability is a major concern, but so too is the rapid obsolescence of both PC hardware and PC software technology.
“Many people think that all sections of Chrysler, Ford, and G.M. (the original authors of the OMAC white paper) are backing OMAC and this is not the case,” says Leslie J. Lee, engineering coordinator for Central Engineering Powertrain Operations at Ford Motor Co. in the U.K. “All three companies are large organizations with a diverse range of opinion. Some people in those companies don’t support the idea much at all.”
Lee has direct experience with open controls from when he helped set up a production line for a Ford engine facility. Use of PCs and open controls there has, in some cases, lived up to its promise but in others fell short, Lee says. “We’ve seen development costs go down, and we have developed open systems more quickly than those centered around PLCs,” he explains. “We’ve also broken the dependency between hardware and software. Our latest line uses Groupe Schneider hardware with software from Phoenix Contact, for example.”
The flip side, though, is that “the standard industrial PC is probably less maintainable than a PLC,” Lee points out. “You can generally hot swap PLC gear but not PCs. And PC-based controls are not as cost effective as PLCs at this point, particularly on smaller machines or automation equipment. We can prove time after time that this is true if you look at it from the system approach, taking into account service and support.”
Lee’s group at Ford ended up developing a hybrid open controller that combined the flexibility of open systems with other features optimized for the factory operating environment. The reason, he says, is that neither PCs nor PLCs today really account for factors such as work practices and a need for quick changeover in factories populated by workers of multiple skill levels.
There is also a worrisome fragmentation of responsibility that can arise when controls come from different vendors. “At Ford some of our production lines effectively put out an engine every 25 seconds. Three shifts man these lines five or six days a week. That is a big responsibility, so we have to be extremely cautious about getting I/O, hardware, and software all from different places,” says Lee. “If you split the controls program into 15 tiny contracts, you end up being a referee.”
Controls vendors that subscribe to the notion of open systems are well aware of these sentiments. They are responding with strategies that address such concerns on several fronts. “Everybody wants an open system, but for any given plant, they want one vendor to supply it,” says Richard Huss, a sales vice president at the Indramat Div. of Mannesmann Rexroth in Hoffman Estates, Ill. The company recently developed an open-architecture concept called System2000. The idea is to mix and match control-system modules to meet specific needs. The first of these is for transfer and dial machines, stand-alone machine tools, and material-handling equipment. Other lines under development have applications in printing, packaging, converting, and automation.
The system employs such standard I/O communication buses as Interbus, Profibus, and DeviceNet, as well as a Sercos fiber-optic interface between control and digital drives. This and PC-based control modules let users chose standard hardware to accomplish specific tasks. Indramat sees this as a way to avoid the traps of proprietary controls.
“Major PLC vendors tend to have an attitude about open controls that might be summed up as, ‘We provide everything anyway, so open control doesn’t matter.’ But the response is that they don’t provide the best of everything all the time,” says Indramat’s Huss.
Renault has successfully taken the open approach in one of its stamping plants. According to Jean Francois Leblanc, head of the Anticipation and Automation Support Group of Renault France, the automaker has been using PC-based controls in a stamping plant there for two years. The PC approach replaced Siemens PLCs and employs both Sercos and Interbus networks for connections to stamping machines. The new controls provide scan times below 6 msec. There have been improvements in stamping machine performance as well, says Leblanc. The up-and-down stamping motion is about 20% faster compared to that available with the older controls. The end-of-motion portion of the cycle is cleaner as well.
The goal at Renault is to do away with control cabinets and minimize electrical wiring. The automaker also wants to minimize its wiring time and cut machine setup time to a few weeks or days. PC-based systems are viewed as a means of reaching these ideals. Renault also thinks that open control systems installed today will be able to work with controls of the year 2008, important because stamping machines have a useful life exceeding 10 years.
EUROPEAN AUTOMAKERS EMBRACE PC AUTOMATION
Machine stations link back to a main control via an industrial Ethernet connection. Similarly, these main controllers send back status data to a central production line server which, in turn, communicates with back-office computers through a plant-wide intranet.
The decentralized scheme reduces PLC and CNC programming requirements because it separates the two kinds of machine controls, Wolf reports. Development and project planning requirements have dropped compared to previous systems. Also helpful is the fact that machine operators can perform all their tasks from any terminal on the industrial Ethernet network. The PC approach, moreover, makes it possible to include diagnostic capabilities in each machine control unit.
PC-BASED AUTOMATION AT DAIMLER BENZ
The first step is a pilot application in one of its auto body shops, planned with automation suppliers that include Groupe Schneider, Phoenix Contact, and Siemens. Daimler aims to create software modules to handle the various production technologies such as welding and painting. The first installations will use PCs combined with coprocessor boards. The coprocessors run a real-time operating system to handle time-critical tasks such as servomotion control and I/O handshaking. Color flat-panel displays sit at operator stations, with an operator interface based on the Windows NT V 4.0 operating system running on the PC. Field bus systems handle messages running between PCs and I/O modules.
PC-BASED PRESS STATIONS AT RENAULT
MAKING CONTROL CONNECTIONS WITH INTERBUS
Interbus networks communicate using what is called summation check protocol. All data from sensors and actuators are summarized in one message. The message periodically goes to all sensors and actuators simultaneously. Thus there is message overhead only once per cycle, resulting in a high message efficiency compared to multimaster or peer-to-peer protocols.
Each Interbus network uses a bus master module that cyclically polls all stations on the network. The bus master can take several forms. For example, it frequently exists as a plug-in ISA board within an industrial PC, or as a daughterboard. It can also be had as a PCMCIA card for interfacing to laptop computers or other suitably equipped controllers.
In addition, Interbus allows for what are called remote-field controllers. These are typically small self-contained controllers that often take the form of a DIN-rail-mounted module. RFCs make it possible to set up Interbus subnetworks which, in turn, can exchange data with high-level networks. RFCs handling such subnetworks can be implemented either as slaves or as bus masters. These remote controllers can be programmed with standard IEC 1131 languages such as ladder logic or structured text. Some also provide a TCP/IP interface for connecting Interbus networks to factory wide intranets.
I/O modules install near the control and signaling units. These convert sensor and actuator signals into bus signals and vice versa. Software for developing Interbus applications handles tasks that include configuration, programming, and graphic display of status. For example, one such package called PC Worx uses a single database to store program variables and configuration data. This common database helps simplify problem diagnosis during startup and operation.