COMPUTER-INTEGRATED MANUFACTURING -- Out With the Old?

BY MARK SMITH

Technology Editor

There's always a danger of any promising new technology or big idea becoming just so much hype. As expectations are built up, so too can be a sense that it all sounds too good to be true. All the talk of computer-integrated manufacturing (CIM) and Job Definition Format (JDF) is approaching, or already reached, the point where some in the industry are tempted to tune out.

Skeptics believe there are a number of reasons to doubt that implementation of CIM/JDF will bring the promised benefits or, at a minimum, they question the ROI. For that reason and others, its adoption will not be as sweeping as predicted, they say. Among the key issues being raised are:

* Why is JDF needed, since CIM—a.k.a. process automation—is already possible with current technology?

* Buying all new equipment isn't practical, so it will take years before the average shop is in a position to broadly implement a CIM/JDF-based workflow.

Ink-key presetting based on color information captured when the job is RIPed has become a common capability thanks to the utilization of PPF (Print Production Format) data enabled by CIP3. Also, some bindery and finishing systems (including folders, cutters and stitchers) offer automatic job setup based on PPF files generated at the imposition stage.

JDF—with its Job Messaging Format (JMF)—incorporates these capabilities, but expands on them in some very important ways, proponents assert. If equipment and system vendors implement the specification in the way its developers intend, JDF will enable:

* Two-way communication, with job parameters transferred down the line and real-time production data reported back up as the work proceeds; and

* Communication of data between workflow components (hardware and software) from different manufacturers, with the promise of plug-and-play connectivity.

Due to the level of development to date, what's been missing from the JDF discussion are real-world examples of its implementation, including analysis of the costs, benefits and barriers to adoption. As has been noted many times, Drupa 04 was seen as marking a turning point in the evolution of JDF—from theory to reality. The first detailed field reports were expected to be released at the show.

What's already seen as a big barrier to adoption is the existing installed base of equipment and software that is not JDF capable or compliant. This obstacle may not be as challenging to overcome as some fear, though.

Doing a capabilities audit of the entire workflow is the best place to start. Systems that are already PPF/CIP3 capable likely will be upgradeable (in the near future) to JDF compliance with new software from the manufacturer.

In a JDF session at the recent VUE/Point 2004 conference, industry consultant Dave Zwang recounted the experience of a company he worked with (Wisconsin-based Action Printing) on just such an effort. He says the shop was able to start building a JDF-based workflow by investing $50,000 in interfaces for systems on the shop floor that weren't already compliant.

Even some 10- to 12-year-old equipment, with the addition of new software, was capable of integrating into the JDF workflow, Zwang says. "The company had just never used those features before," he notes.

As a result of this effort, Action Printing was able to reduce its head count in customer service and the bindery, while also cutting waste, the consultant reports.

Some degree of computerized control typically has been available on printing equipment for years, even if it doesn't rise to the level of PPF support. Therefore, a more aggressive retrofit may provide direct JDF support or, alternatively, it may be possible to tap into those electronics another way.

Building a Bridge

One option being pursued by manufacturers such as MAN Roland and others is to provide "middleware" or bridge software for incorporating legacy systems into JDF-complaint, automated workflows, reveals James Harvey, executive director of CIP4.

Another solution being pursued is development of departmental-level controllers that can communicate in JMF/JDF and act as translators to legacy devices, Harvey adds.

As a last result, the JDF specification provides a means to incorporate manual interfaces—as well as manual labor process nodes, the CIP4 exec points out. "Standalone computer terminals or punch pads can be used to relay instructions to an operator of a legacy system and to collect production data upon completion of the job," he explains.

Despite its global vision of the process, JDF implementation is not an all-or-nothing proposition, Harvey says. Printers can start small and implement JDF in one process area, then build out from there over time, he advises.

How much of the integration work printers will have to do themselves is an open question. But, this option may not be practical for all shops depending on their resources.

Melinda Monti, training manager at Vertis Inc., was part of another JDF panel discussion at VUE/Point. As a company with almost $2 billion in sales, Vertis obviously has substantial resources to call upon. It is looking for vendors to provide JDF data in an accessible, editable format so "we can build our own bridges and put in our own information," Monti reports. "We want open systems that we can customize."

Fellow panelist Scott Borhauer, central premedia manager at Brown Printing, also has the resources of a large organization behind him. Yet, Borhauer says it is not practical for any company to make the investment required to retool an entire printing operation for JDF at once. Brown's IT staff is being called upon to connect its existing systems, he notes.

"IT people are replacing operators who understand the trade," Borhauer says.

Since before there was JDF or before people called it CIM, a form of system integration has been available in the printing industry. Direct Machine Interface (DMI) technology provides a machine-to-computer link by capturing data from press and postpress equipment, and transferring it to an MIS application.

Logic (now EFI) was a pioneer in the area of DMI solutions for the printing process with its patented Auto-Count system. According to Gerald Walsh, product marketing director for MIS products at EFI, DMI systems can connect directly with a machine's computerized control panel, if it has one, or special sensors can be added to the equipment to capture the desired data.

A patented part of the Auto-Count technology for web offset presses is adding a sensor to the waste bin so it can be weighed and the measurement used to calculate the number of good impressions, he adds.

Information such as run schedules, production logs and job tickets can be displayed on a system's monitor, providing a flow of information out into the plant, as well.

Auto-Count is sold as a standalone product, so a number of users have connected systems to MIS applications from other vendors or their own custom solutions, Walsh says. JDF currently is not an option for making such connections, since Auto-Count was developed prior to the specification being written, he adds.

"We do see the value in having Auto-Count be JDF-based, but that is a vision statement from the EFI standpoint," Walsh continues. "We have not begun the development of a JDF-based product." Such a system would have the potential to communicate with all JDF-compliant MIS applications, he says.

While its solution takes a slightly different form, DiMS! organizing print already has introduced what it terms a "JDF-ready" DMI module for its MIS solution. The module reportedly features a standardized, XML-based interface and provides a Web-enabled workflow that connects with production equipment. Users can interact with the system via a Web browser.

There is an even more basic form of process integration available in the form of shop floor data collection, EFI's Walsh points out. Data can be collected utilizing a monitor and keyboard setup, and product information can be displayed on-screen, he says. "It's basically the communication portal for the production worker."

The drawback to this approach is that information about the processing of a job typically isn't entered until after a step is completed, Walsh notes. Even so, he still sees a need for this type of portal as the industry moves toward direct connectivity via JDF with real-time reporting. As long as human operators are still involved in the process, they will want a means to provide explanations for why a job goes off schedule, Walsh believes.