|
|
|
|
|
|
| Information | Education | Business Development | Technical Resources | Members |
About CIP4 and JDFContent
Quick Facts
(Sources: InfoTrends’ Production Software Investment Outlook and CIP4 CIPPI Case Studies) Introduction to CIP4 and JDFThe International Cooperation for the Integration of Processes in Prepress, Press, and Postpress Organization or “CIP4” is a not-for-profit standards association, whose mission is to foster the adoption of process automation in the printing industry. A global organization with representatives from 31 countries, CIP4’s membership is organizational and boasts a diverse membership that includes printers, prepress companies, publishers, vendors of graphic arts systems and software, integrators, distributors, consultants and educators. Currently, CIP4 consists of over 1,600 individuals from approximately 300 members. These individuals participate in one or more of 17 working groups that are focused on technical subjects as well as educational and automation promotion activities. Membership is open to any company involved in the graphic arts, and “meetings” are primarily held via internet meeting and conference call software, for the convenience of everyone involved. Members meet twice a year for face-to-face “Interop” events, where technical tutorials are regularly provided for new members and working groups can meet and discuss topics that are best discussed in person. Furthermore, Interops provide and opportunity for members to test systems in development with other members in a private, yet very welcoming and informative environment. In addition to the Job Definition Format, PrintTalk, and the Print Production Format (often called “CIP3”), CIP4 provides a variety of resources to its members and the industry, including:
All this and more can be found at CIP4’s website at www.cip4.org. Membership is organizational and provides access to benefits to all staff members, and is priced at $3,300 for vendors of systems and software and $175 for users of automation systems, such as printers, prepress services, and publishers, as well as for educational institutions and individual consultants. CIP4 Mission StatementMission Statement: Supporting Principles of Operations: The organization shall seek to promote the adoption of process automation globally, through the creation and dissemination of information on process automation methods and solutions through educational programs, industry events, trade media, online systems, social networking and other means. CIP4 management will also promote active participation in CIP4 programs among the membership and will promote the adoption and understanding of CIP4 standards within the membership. CIP4 may create infrastructure programs, such as certification, to support process automation in the industry, and will work to promote adoption and compliance to CIP4 standards among its members. CIP4 will conduct operations to ensure that income, in dues or from other sources, shall be sufficient to fulfill this mission. CIP4 and its members will also strive to grow membership in order to increase adoption of CIP4 standards throughout the industry. Adopted by the CIP4 Advisory Board on May 9, 2011. The CIP4’s HistoryCIP4‘s predecessor, CIP3, was formed by Heidelberg and was managed by the Fraunhofer Institute for Computer Graphics. CIP3 created the Print Production Format or “PPF,” which has found success in ink key pre-setting and postpress operations. Adobe, Agfa, Heidelberg and manroland created the first draft of JDF and offered it to CIP3 on the contingency that CIP3 be reorganized as an open and international standards association, and this reorganization led to the creation of CIP4 in 2001. Once the transfer was completed, JDF 1.0 was published. It was not possible to implement JDF 1.0, rather it served as a “straw man” document that members of CIP4 could shape, change, and improve, a definitive starting point. JDF 1.1 and 1.1a were published in April and October of 2002, resulting in the first version of JDF that could be implemented by vendors, and at drupa 2004 the first wave of JDF-enabled products hit the market. Since then, JDF has been updated several times. Each time the basic structure of JDF has been preserved and the specification was expanded to include broader aspects of print production. Initially optimized for sheetfed offset printing, JDF has been expanded to include digital printing, preflighting, web offset printing, packaging, layout applications, newsprint, and more. JDF is also recognized as a nominal reference in several ISO and ANSI standards. Furthermore, PrintTalk, another XML-based specification, in this case focused on the business transactions of print buying and sell, was transferred by NPES in 2005 to be maintained by CIP4. Since then it has been brought inline with JDF so that data captured in business transactions can later be carried forward as needed in print production. JDF OverviewJDF is based in the Extensible Markup Language (XML), but not entirely. XML was selected as the underlying standard language for JDF because it is already a widely recognized language and is a standard. The application programming interfaces for programming languages such as Java, C+ and .NET all support XML directly and there are many XML tools, databases, and so on readily available on the market. XML has found a niche and is widely used for communicating content between back-office systems and web servers. XML provides rules of syntax and default data types; however, XML alone is not enough. XML does not require that a document type definition or schema be defined against which “instances” of XML can be checked or “validated.” Validation is critical to many types of applications, especially where data is going to be imported into a database (as in the databases behind your workflow and MIS systems.) JDF is based on the Worldwide Web Consortium’s (W3C) XML Schema Recommendation. By using a schema, JDF allows for validation (think preflighting, but for metadata) and allows CIP4 to create user defined data types, (ex. “Rectangle” or “Matrix” as used in transforms, or “NamedColor”) The JDF Specification also provides specifications for file naming (e.g., URL/URI usage for hot folder exchange) and methods for packing JDF and content files together in MIME Multipart Messages. Both make use of the hypertext transmission protocol (HTTP), which also assumes TCP/IP networking. The selection of a networking protocol and method of exchange are just as important to your process automation program as is the XML component of JDF. The JDF Specification is freely available to the public as is the JDF schema at www.cip4.org. The public schema covers all the requirements of our very flexible environment. In practice, you may want to create a subset of the schema that only uses the components that correspond to your workflow. For the most part, vendors implement JDF in their systems; although some printers with in-house development staff have done their own development. For the most part, the printer’s role in implementing JDF is that of project manager. JDF is very flexible and does not mandate any given workflow. It is up to the printer, working with their vendors to design the workflow that best suits their needs. Almost all printers have some JDF capabilities in-house, but that does not mean that devices will automatically start talking to one another; rather, like all equipment purchases, devices in a JDF implementation must be set-up and tested. Although automation is not new to the printing industry, what JDF does is make automation accessible to printers of all sizes. Without JDF, automation projects are very expensive custom integration projects in which all aspects of production must be considered. With JDF, a printer can begin implementing automation on a limited basis and add process and equipment at a later point … knowing that if all new equipment supports JDF, they will not have to reengineer processes that are already automated. This is why it is recommended that printers make JDF a requirement for all future equipment purchases. JDF Product CertificationNo single device (i.e., printer, press, imagesetter, etc.) is likely to implement all that the JDF specification provides for. For instance, if you are in the digital printing business, you may not care to facilitate data on hard case binding. A RIP need not facilitate JDF preflighting. A Stitcher probably doesn’t need to handle image rendering data. To specify exactly what individual classes of devices need to do with JDF, CIP4 has introduced “Interoperability Conformance Specification” (ICS) documents that provide the standard for individual classes of devices. ICS documents look at the interface between the manager of a job, (i.e., a workflow system, Print MIS, pressroom management system, and so on), and the worker (e.g., the system or software that will perform the desired process. In addition to a few base ICS documents that applies to all JDF-enabled devices, ICS documents have been published to cover a variety of interfaces, including:
These ICS documents define the roles of the “manager” and “worker,” including their ability to read and write JDF options as well as additional data typing, defining how jobs files are to be exchanged or identified, and required support for particular JDF processes and resources. It’s important to note that ICS documents do not add to the JDF specification, but rather, they provide additional constrains and a subset of JDF specific to the interface that they define. ICS documents are used as the basis for certification testing conducted by PIA/GATF. This JDF Product Certification is well established and printers should look for the “JDF Certified” logos on certified products. Please see www.cip4.org/certification/intro.php for a complete description of the certification process and for a list of certified products. The Four Main Functions of JDF JDF Staple Fold JDF has four main functions. First, it provides a single common language that supports the lifecycle of a print job. This is what people mean when they refer to JDF as a “Job Ticket” language, but it is much more than that. The second function is to provide a command and control language for devices on the shop floor. This aspect of JDF is call the Job Messaging Format or “JMF” and many folks talk about JMF almost as if it is a separate specification, but it is integral to JDF. JMF allows the controlling workflow or MIS system in a process automated environment to tell a device to start and stop jobs, reorder the queue, and so on. Third, there is inherent in JDF a flexible methodology for constructing workflows and providing the command, control, and configuration of plant automation and job production. The fourth main function was added to JDF 1.2 and that is automating the handshake, which is accomplished with device capabilities functionality. For instance, in JDF there are five staple folds that a stitcher may use. If a new stitcher is added to your JDF workflow, the governing workflow or MIS system must know which of those five folds the new stitcher supports. Communicating the set of JDF elements and attributes supported by a device to the MIS system or workflow system is creating the “handshake.” Device capabilities allow JDF 1.2 capable devices to be automatically queried for the details of what aspects of JDF they can and cannot manage. This is an important step towards total “plug-n-play” interoperability.  The Role of JDF as a Job Ticket Format The analog version of a job ticket may be an envelope or folder with routing information that contains instructions and specifications about a job. It may start in sales with the purchase and customer information and progress through estimating, scheduling, and into production, and through the shop floor. As each employee does their part, they sign off on work completed and the job ticket moves on. JDF provides a digital method for accomplishing the same functions. Like analog job ticket, it may begin with metadata about the job provided by the customer or gleaned from sales. This customer “intent” information may not be enough to drive the production process and it must be added to. The customer may specify “80 lbs. offset matte white,” but in estimating your staff will add a brand name and perhaps confirm availability and the actual quantity of sheets or rolls you’ll need to print the job, to include overage to account for inter-process spoilage and so on. Likewise, in JDF there are two basic categories of job input data and materials: Intent and Process. Customer intent is preserved but process data is added as the job progresses through its life cycle until the job can (and is) processed; hence, to use JDF does not mean that you must collect all data about a job upfront, you can add data to a JDF instance (e.g., a single “job ticket” or JDF “document”) throughout the lifecycle of a job and the data does not all have to be keyed in either. Part of the idea behind JDF is to preserve job metadata at its point of entry in order to eliminate re-keying and its inherent problems of miscommunication, redundancy, and confusion. Some of the likely sources of JDF metadata include:
Although some companies may literally use JDF as “tickets” in that they maintain a single file for a job and keep adding to it, in most cases the “job ticket” is a virtual construct maintained in a database within the software that controls your workflow. At its heart, JDF is an exchange format for use between systems. When a workflow system wishes to drive a device on the shop floor it need only prepare and deliver a JDF instance with the specifics for that particular step of the process. So JDF is more than a job ticket, it is really a standard language for preserving job data throughout the lifecycle of a print job. In fact, two of its important functions are providing for the collection of both quality control (Q.C.) data as well as audit information about each process (i.e., start time, operator/shift, errors/waste, end time, and so on.) Since audit and Q.C. data is provided electronically and directly from devices, it can be used to troubleshoot the difference between actual and estimated costs, bottlenecks in the workflow, and automatic adjustments to inter-process overage, plus it can be used to improve management’s overall view of production to help them plan improvements, maximize resource allocation, and provide customers with better job information. 1) PrintTalk Schema’s make use of JDF and JDF incorporates several PrintTalk objects, including support for Request for Quote, Quote, Purchase Order, Order Confirmation, Cancellation, Refusal, Order Status Request, Order Status Response, Proof Approval Request, Proof Approval Response, and Invoice transactions. Also see www.cip4.org/documents/printtalk/. The Role of the “MIS” SystemThe term “MIS” system, as used in the JDF specification, is a bit a misnomer. MIS stands for “Management Information System,” a term in the 1960s that meant a reporting system that later in the 1970s and 1980s grew to incorporate accounting, billing, inventory, and other disparate management oversight functions. “MIS” as used in JDF is for the most part meant to cover workflow and production management systems — the business and production functions that one would expect to incorporate in a process automation project — and in our industry there are a variety of sizes and types of MIS systems ranging from enterprise-wide systems that may incorporate management reporting, accounting, and so on, to departmental workflow systems that may only control prepress operations. At their most basic, these systems must be able to accept JDF input and decompose the JDF and store the data in its internal database, and they must be able to compose JDF from its database for output. (Beware of one-way workflow systems — in the long-term, systems that take in JDF, but cannot output JDF may prove to be roadblocks to your process automation program.) This requirement implies that these systems must be able to read and validate JDF as well as write and validate JDF. Validation is the process of checking a JDF instance against the public JDF schema or a working subset to ensure that the rules of structure are adhered to. Some companies may integrate validation functions, while others may use a third-party tool. It’s important to know that not any off-the-shelf XML schema validation tool can be used. In the JDF specification there are certain “if-then” conditions that an off-the-shelf generic validator will not be able to validate. If an output ICC color profile is associated to an image that is incorporated into a document file that also has an output ICC color profile, and those two profiles don’t match, you and I know that the document’s output color profile takes precedence and you may have to apply a transformation to the image. Conditions such as these are common to the graphic arts and in the JDF specification you’ll see many cases where a default is established at one point if a certain value exists elsewhere in the JDF instance. JDF validators, available from CIP4 as well as commercial sources, take these “if-then” conditions into account, as well as embedded systems that many vendors are building into their JDF “MIS” systems. Your JDF MIS or workflow system must also be able to command the devices on the shop floor to act upon a job; after all that is one of the main objectives of process automation and computer integrated manufacturing. To provide this command and control, your JDF MIS or workflow system must understand, read, and write JMF (more on that below) and must be able to store and utilize the input and parameter requirements of each device in your workflow.  Resources: Forming the Link Between Process “Nodes” The most important requirement is that your JDF MIS or workflow system must be able to organize a JDF job. JDF uses a very “Lego-like” approach to workflow. The specification identifies approximately 80 separate processes individually to which you can associate several “resources.” There are about 160 resources specified in JDF and they are input and output parameters (metadata) that can be associated to a process. In JDF workflows, the output of one process “node” is the input to the next; hence, the singular term “resource.” Once all of the required inputs for a particular job are determined to be available by a system, the next process in your workflow can then proceed. For instance, the output of a platesetter is an image plate and that image plate is the input to a press. The press cannot begin operating until the plate is imaged. Even legacy systems with no on board computers and manual tasks can be managed this way. There are several features in JDF that can be used optionally to accommodate even the most complex workflows. For instance, JDF allows for the spawning and merging of jobs. This feature may be used where several different signatures print concurrently on different presses, or a cover is printed concurrently and the pieces are assembled later in bindery. You can create “combined process” that act as one with one set of inputs and outputs in a pipeline. For instance, many digital printing devices consist of a combined RIP, printer, and finishing unit and yet there is only one set of inputs and outputs. A conventional printing is actually a combined process, in that you may have ink, paper, cutting, color measurement, and other processes running concurrently. An ink system may use a special variant of pipelining that incorporates maximum and minimum values — when the ink well or tank hits a lower level, the inking system goes off-line until it is refilled, and refilling may be defined as to hit a certain maximum quantity. These are options that you may want to be aware of when selecting a JDF MIS or workflow system. Some vendors are providing options for JDF MIS and workflow systems such as middleware that can convert back and forth between JDF and legacy device controller languages. For instance, several of the major press manufacturers have been providing fairly automated presses for several years and such middleware will be important to making your transition from proprietary process automation languages to a JDF-enabled environment. Optionally, you may want your JDF MIS or workflow system to either include, or have bridges to, estimating, CRM, scheduling, inventory, management and customer reporting, accounting, billing, ecommerce, and ERP systems. For instance, an integrated paper inventory system may allow you to reduce inventory levels, minimize spoilage, and get closer to a “just in time” system. Another important option to consider is your JDF MIS or workflow system’s ability to handle extensions. Although the JDF specification provides a fairly exhaustive catalog of all the XML elements and attributes you may want to associate to each process and resource, it’s doubtful that the specification incorporates every conceivable possibility. You may encounter vendors who have unique functions that require extensions to the JDF specification, and you may have even developed your own internal systems for dealing with customer or market specific data requirements and may find it useful to employ JDF extensions of your own. Whereas a front-end system or device on the floor only needs to pass along an extension that it does not understand, a JDF MIS or workflow system must be able to understand and make use of extensions. If you add a device to your shop floor that requires a certain job parameter that is only available as a JDF extension, then your JDF MIS or workflow system can only drive that device if it can provide the required value for the extension, otherwise, it can never know when a job is ready to proceed in the workflow! Extensions are important, but should be used with caution. Your vendors should be able to provide you with documentation for extensions and CIP4 encourages both vendors and users to submit extensions for possible inclusion in the JDF specification. The Role of the Job Messaging FormatSo far we’ve talked about JDF MIS or workflow systems and devices on the floor. The MIS or Workflow system acts as the JDF agent and it may communicate with and command a controller. The controller is an important concept in JDF. A device on the floor may have an embedded controller, the controller may be a separate physical device, or the controller may actually control more than one device. We have even seen a couple of “departmental” controllers that deal with all the devices in a department (e.g., Postpress) enter the market. The language used to communicate between JDF agents and controllers is the Job Messaging Format or “JMF.” JMF is part of the JDF specification. JMF also is built in XML and is part of the JDF schema. JMF allows a controller to communicate information to a JDF-enabled MIS or workflow system, such as events (start, stop, error), status (available, offline, stalled, etc.), results (count, waste, etc.) and other details such as who the current operator is. A controller may also “register” with a JDF MIS or workflow system, letting it know it is available, and where a controller controls multiple devices, it can provide registration information for the devices it supports. Note: This is information like make and model and is not a substitute for device capabilities as described above.  An MIS or workflow system may use JMF to command devices on the shop floor and may even be able to change the order of jobs in the queue. JMF messages may also be unidirectional (the MIS system provides the commands, but the controller does not respond) or bidirectional. Determining what JMF options will be required of your process automation strategy is an important part of creating an effective JDF equipment buying policy. JMF can also be used by one controller to provide commands to another controller. This is an important feature for supporting combined process and pipelining as describe above. Strategies for Implementing JDFThe first step towards process automation and JDF implementation is to make someone responsible for developing a strategy and overseeing implementation. You should also be sure that you have the support of senior management and the availability of departmental heads and key employees in the planning and implementation program. It is also recommended that you involve select customer representatives and vendors in your team. In the case of vendors, you will want to learn what your current vendor’s JDF implementation plans are. What products (that you already own) include JDF-enabled options or features? Document your current environment and compare your vendor’s upgrade path to equipment and systems on the shop floor. Are there any holes? Are you working with vendors that don’t have timely JDF implementation plans, or products that will be un-supported in the future? Do you have custom built systems that may require JDF functionality? Or perhaps you need a middleware to communicate between some legacy devices and your JDF systems? Do any of your vendors provide such middleware? Enterprise-wide JDF implementation is probably not achievable in the short-term and odds are you’ll need to figure out how to phase JDF in to your operations over the course of a few years. The key to success is capturing a return on your investment as soon as possible. Every company will have different priorities and different situations. Consider what customer niches or production lines, or departments, or plants (for the big companies) are due for capital replacement or are in the greatest need for improvement. Also consider your company’s objectives and where it is most likely to realize a return in the short-term. By focusing on a quick return from a limited implementation, you will benefit from the experience and learn to maximize your return as you approach enterprise-wide implementation. What your priorities are and how the above will impact your company will vary from company to company. Certainly, some companies have implemented a degree of process automation with proprietary systems, and in the short-term, less will be gained in those areas; however, in the long-term, maintenance and support for proprietary systems will become a burden compared to maintenance and support for JDF-enabled systems — one of the universal advantages of having a common language for all devices in our industry! The situation is similar to the move to CTP. If you were already accepting digital files from customers and outputting imposed film, the move was easy and the gains relatively marginal compared to companies that were still using process cameras and stripping film … they had much farther to go and more to gain from the change. Once you’ve established your priorities and objectives for your return on investment, don’t forget to establish how you will measure and evaluate success. Review some of the CIPPI Award winning case studies at www.cip4.org/cippi; these case studies are very detailed and a great source of ideas, lessons learned and the kind of detail that is hard to find. Finally, prepare a purchasing policy and acceptance criteria that you can apply to JDF purchases … buy smart! Where to find JDF Tools & ResourcesThere are several free and publicly available resources on that can be found at www.cip4.org, including a CheckJDF application and a JDF Editor, as well the specification and schema. And of course there is this JDF Marketplace resource, which includes information on products of all types, as well as information on development tools, consulting services, and educational programs and training. Check the CIP4 website for new editions of the JDF Marketplace, as it is published twice a year. You can also sign-up at www.cip4.org for a free JDF Bulletin — an informational email newsletter that includes updates on changes and developments, product announcements, case-studies, and articles written by members of CIP4. CIP4 membership for users (Printers, publishers, buyers, consultants, and prepress services) is only $150 per year per company and all of your staff can gain access to member-only material, including access to email forums and working groups, sample code, an archive of documents and email messages, and the JDF programmers API (for you do-it-yourself types.) The forums provide a great resource where you can get answers to technical questions. CIP4 in conjunction with the IDEAlliance + IPA offers a 13 session JDF Expert Certificate program. This program is optimized for technical staff and management at printing, prepress, and publishing companies and is taught via the Internet in both live and streaming (recorded) versions. For more information see www.ipa.org/jdf/.) Don’t forget to ask your vendors (including your distributors) about technical support and training they may be able to provide. Several vendors are providing seminars around the globe on JDF topics. CIP4 also manages JDF Users Forums in German, Spanish, French, and Japanese (see www.cip4.org/groups/user_groups.html.) In North America, there is also a Automation Solutions Network, managed by Printing Industries of America, that meets three times a year (see www.printing.org/automation). For members of CIP4, there is also a CIP4 Japan Technical Working Group and Business Networking group that operate in Japanese. |
For comments or questions about this page please send an email to
|
