Positioning 3DPDF in Manufacturing How to Understand 3DPDF when Compared to Other Formats

Transcription

1 Positioning 3DPDF in Manufacturing How to Understand 3DPDF when Compared to Other Formats A 3DPDF Consortium Whitepaper Author: David Opsahl Executive Director 3DPDF Consortium Date: January

2 Contents Introduction... 3 Formats and Standards... 3 Terminology... 5 Application Application Data Exchange... 6 Data Exchange with STEP... 7 Background on STEP... 7 The Exchange Process using STEP... 8 The Exchange and Visualization Process using JT... 9 Background on JT... 9 The Exchange, Visualization and Publishing Processes using 3DPDF Background on PDF Background on U3D and PRC The Data Exchange, Visualization, and Publishing Processes using 3DPDF Publishing with 3DPDF in Detail Summary

3 Introduction The introduction of three-dimensional (3D) geometric support within the Portable Document Format (PDF) standard has added a new dimension of complexity to the discussion around formats and their use. End user organizations, software developers, and systems integrators not to mention analysts and bloggers all have had a hard time figuring out how to position the various formats in their various discussions and in their adoption strategies. The purpose of this paper is to highlight for the reader how these formats are similar, how they are different, and what role they should be considered for in a data architecture within an organization or set of relationships between organizations such as an OEM and its suppliers. Formats and Standards To begin, let s have a short discussion on formats and standards. There are two primary types of formats: Proprietary formats o These are the formats that are used to define product design data in manufacturing used by the majority of authoring tools in the marketplace. The most common data type represented in these proprietary formats is geometric data, but robust formats also increasingly include other information useful throughout various stages of the product lifecycle, such as product manufacturing information (PMI) which includes geometric dimensioning and tolerancing (GD&T) data, as well as data such as inspection points, weld points, etc. Descriptions of these formats are generally regarded by the software developers as intellectual property and protected appropriately. Open formats o Many of the software developers providing authoring tools have implemented open formats which, to one degree or another, have definitions which are accessible to third-party application developers and customers who wish to do their own application development. While in some cases these open formats were created to allow a subset of the design data to be used downstream of engineering by these third party developers, in point of fact the purpose of these open formats is often to enable interoperability between application suites provided by the software developer. Similarly, there are two kinds of standards: 3

4 De-facto standards o These are formats that, due to popularity within a given industry, or pervasiveness across a broad range of industries, are commonly found within manufacturing organizations. What is important to note about de-facto standards is that: The intellectual property belongs to the developer, regardless of how much detail is provided to the third-party application providers The developer has control over the definition of the standard, and can change it at will with or without the advice and consent of the user community The developer can also determine who has access to the format, and for what purpose, regardless of the value to the user community International standards o These are standards in which all relevant interest in information, data, and intellectual property are in the hands of the marketplace, and development of the standard is driven by the community itself. The standard may have been developed as a cooperative effort by the community, or it may have started as a proprietary format, which achieved a de-facto level of adoption, and then was turned over to the community. Let s summarize this discussion with the following: Proprietary formats provide the developers with the means to enable rapid innovation within their products, which benefit the community at the product realization stage Open formats and de-facto standards can facilitate interoperability, but at the price of not being archival quality, and can place the economic interests of the developer ahead of those of the community where they are used International standards by their nature are stable and can be slow to evolve, but protect the investment in tools and processes of the community by ensuring that the data they encapsulate is always capable of being leveraged downstream, and recoverable from an archive repository For the purposes of this paper, we are only going to consider formats which are, or are about to become, international standards. This includes: STEP JT PDF In the case of PDF, what we will discuss is how PDF, itself an ISO standard, references for the purposes of 3D data representation, U3D (an ECMA standard), and PRC (a soon-to-be ISO standard). Although this may seem convoluted it is one of the strengths of PDF in the role it plays in communication. 4

5 Terminology In trying to understand how to compare or position the roles of various formats, there are some terms used in this paper that the reader will benefit from understanding up front. Visualization Communication Derivative Rendition Transformation As it is commonly used in the manufacturing industry, visualization is used to perform any number of activities, such as digital pre-assembly, human factors analysis, or simply being able to interrogate a design feature of one sort or another also called view/measure/markup. Almost always refers to 3D data. Although not commonly used like visualization, the term communication is being used in the context of this paper to refer to the act of providing all the relevant information, not just 3D data, need by someone in a given job role where the information is contextually correct for the role, presented unambiguously, and with no barriers to consumption. The term derivative is being used increasingly to describe a formatspecific representation of a design authority that is one or more transformations removed from its original authoring environment. For instance, a product designed in a CAD system would be considered to be the design authority when represented in its native format; publishing that design to STEP or JT would be considered to be a derivative representation of the design authority. Outside of manufacturing, every industry considers document management, also called Enterprise Content Management, to be a key IT strategy since the production and management of documents is central to every business. In this context, a document usually authored in Word, Excel, or PowerPoint is that particular industry s equivalent of the design authority in manufacturing. The term rendition is commonly used in these cases to describe what a PDF is; a rendition of the authored document that is used for distribution to provide (and collect) information relevant to a particular job role. That definition is exactly the same in the context of this paper, with the exception of the fact that included in our case is 3D data within the PDF file. The act of processing data contained in one format, to a second or derivative format. For instance, going from a native CAD format to STEP 5

6 Exchange Publishing or JT, is a transformation process. Similarly, going from JT or STEP to a format native to any application, is also a transformation process. Exchange is a meta-concept; one that is defined using other concepts. In this case, as is commonly used in manufacturing, exchange means the transformation of a native format into a derivative format, the delivery of that derivative format data to one or more third parties, and the transformation of it back into one or more proprietary formats. In the context of this discussion, publishing is another meta-concept; the act of taking a derivative format and incorporating it with other data to create a rendition, which then becomes a distributable information package a document if you like, but entirely digital and interactive to be used in a large variety of use cases, including but not limited to regulatory compliance, communication with customers and suppliers, process compliance, etc. Application Application Data Exchange One way to clarify the role that these various formats occupy and excel at, is to look at the generalized use model. For instance, much of the use of formats such as STEP and JT has been to facilitate the exchange of data between applications. Transformation MBD/MBE represented (usually) by CAD/CAM/PLM system Application¹ STEP JT 3DXML XVL Derivative format Can be another MBD/MBE application Could also be a standalone app such as DMU or View/Measure/Markup Application² Transformation Figure 1 - Application Data Exchange Figure 1 illustrates this concept using the terms we ve outlined in the previous section. In defining the product or object to be built, the owner of the design authority strives to create a model-based definition (MBD) of the product or object. If the owner has an advanced IT strategy, they may be 6

7 employing model-based enterprise (MBE) practices to combine MBD data with other relevant data such as that found in a PLM, ECM, or ERP system. Other organizations, such as design partners, have a need to consume that data to facilitate their role in the manufacturing process. Frequently, but not always, that consumption is initiated by an application. Take the case in Figure 2. In this simple example, an organization designing the part is sending the data to a supplier to enable CAD NC Derivative the supplier to machine the part directly from the modeling machining format application application model data, which if the derivative format has been properly selected *and* has been properly Figure 2 implemented on both sides will allow the manufacturer to produce that part with maximum speed and best quality, since no interpretation need be made by the consuming manufacturer on what precisely is to be made. Therefore, one can confidently state that the data is being consumed application to application or machine to machine. Data Exchange with STEP Before we begin, let s briefly review what STEP is to level-set the reader. Background on STEP STEP is not really a format per se; it is an international standard (ISO 10303) that has a multitude of parts organized into groups (description methods, implementation methods, application protocols, application modules, and many more). In total, STEP consists of several hundred parts and is the largest standard in the ISO community. The key thing to remember when discussing STEP is that its purposed is defined as a standard for the computer-interpretable representation and exchange of product manufacturing information. It is, in other words, the very embodiment of application application data exchange. Unique in this industry, STEP has been from its first day, envisaged as an international standard, containing no proprietary intellectual property. STEP was developed as a true community effort, which originated in the aerospace industry, as a means to exchange information between airframe manufacturers and their primary suppliers, such as turbine engine manufacturers, where dissimilar MBD applications are the norm. It has expanded in scope to other industries, and beyond geometry to include other domains as well. Its verbosity and granularity make it ideally suitable for long-term archiving purposes. 7

8 While this paper is not intended to be a discourse on the scope of STEP, suffice it to say that STEP can represent an enormous variety of data: Geometric information Product manufacturing information Product lifecycle support information NC manufacturing information Electrical systems information This actual list is truly staggering. What s important is to recognize that the level of granularity in the kind of information STEP can represent is matched by no other format in existence, proprietary, open, de-facto, or otherwise. This makes it ideal for archiving purposes, given the level of information captured, and the absence of any dependence on a particular application. The Exchange Process using STEP Following on the discussion about application application data exchange, let s look at an example of how that occurs when using STEP for exchanging MBD/MBE data. From a process perspective, Figure 3 MBD Authoring Application design authority CAD and PLM data Archivable STEP data multiple AP s possible XML data Archivable MBD Receiving Application modeling, NC, etc. derivative representation CAD and PLM data Not Archivable shows how this occurs. Some key points to remember: Figure 3 - Data Exchange Using STEP The derivative data, without a consuming, conforming application, has no value. The data being exchanged can be simple geometry (via AP203), moderately complex MBD data (AP203, AP214, AP242), or considerably more complex (AP203, AP214, AP242, and AP239). This is only the exchange of data which is represented by the respective STEP parts, and may or may not represent the actual use of that data downstream 8

9 Although it is possible to use STEP data for the purposes of visualization, due to its verbosity it is not as well suited for such uses as is JT To ensure that the derivative precisely matches the data authority, the employment of validation tools (software) and processes needs to be considered No rendition is created, and nothing is published this means that value added to the process has to be created by the user of the receiving application The Exchange and Visualization Process using JT As we did for STEP, let s discuss briefly the origins and use of JT. Background on JT The JT format has been around in one form or another since the 1990 s, as has STEP. JT was originally developed by Engineering Animation, Inc. and Hewlett Packard as the DirectModel toolkit (initially Jupiter Toolkit). When EAI was purchased by UGS, JT became a part of UGS Corp. s suite of products. Early in 2007 UGS announced the publication of the JT data format easing the adoption of JT as a master 3D format. Also in 2007, UGS was acquired by Siemens AG and became Siemens PLM Software. JT is the common interoperability format in use across all of Siemens PLM Software product suites. JT is also used as both a data exchange format between design partners and manufacturers, as well as for visualization applications such as digital preassembly (also called digital mockup or DMU) and generalized visualization, more commonly referred to as view/measure/markup (VMM). Siemens has supported the development of JT as an ISO standard; approval occurred in December When compared to STEP, JT is far less verbose, and focuses primarily on the geometric representation of the product or object to be built, as well as attribute information associated to the product, including but not limited to product manufacturing information (PMI). JT also contains definitions of both exact geometry via non-uniform rational b-splines (or NURBS) as well as faceted or tessellated data of varying levels of accuracy and compression. Unlike JT, STEP does not consider lightweight representations of a product or object, nor does it concern itself with compression. Therefore JT has advantages when being considered for downstream use. Unlike STEP, JT was developed initially as a proprietary format to support the DMU and visualization applications of Engineering Animation Incorporated (EAI), which when adopted by Unigraphics (the original acquirer of EAI which then itself was acquired by Siemens to create Siemens PLM Software) was used as an exchange format within what are now the Siemens PLM Software applications suites. This was necessary as Unigraphics not only acquired EAI, it also acquired Structural Dynamics Resources Corporation, a developer of CAD/CAM and PDM software, as well as Tecnomatix, a developer of manufacturing engineering applications. During this time, Unigraphics made the decision to create the 9

10 JTOpen community, which allowed customers and developers to contribute to the evolution of JT, while allowing Unigraphics/Siemens PLM to retain control of the intellectual property and distribution. JT therefore, became a de-facto standard. By releasing control of the IP, Siemens has allowed JT to be considered for adoption as an international standard. The history of JT is useful in understanding where it excels. Having as its origins the primary use case of defining highly detailed geometric information that was both accurate and lightweight, as well as key attribute information such as PMI, JT became purpose-built for certain uses cases such as digital mock-up, visualization, and limited forms of data exchange. It also has the ability, should the user desire, to exchange. The graphic in Figure 4 shows this. Figure 4 - Using JT for Exchange and Visualization One of the key characteristics that distinguish JT from STEP is this duality of being able to be used in cases where direct data exchange from one MBD application to a second, as well as in cases where visualization is desired. JT tends to be most useful to large organizations that are Teamcenter users, and employ more than one of the various Siemens PLM Software product suites. Since JT is used heavily to communicate visual information and product structure between those applications, it makes sense for those users to leverage the JT data wherever possible. The Exchange, Visualization and Publishing Processes using 3DPDF Based on the title of this section alone, one can readily begin to understand that the general use of 3DPDF has a completely different purpose than either STEP or JT. Explaining that difference is, as stated in the introduction, the purpose of this paper. Background on PDF Much the same as the evolution of JT, the Portable Document Format (PDF) was initially a proprietary format, then evolved into a de-facto standard, and eventually became an international standard. Portable Document Format (PDF) is a file format used to represent documents in a manner independent 10

11 of application software, hardware, and operating systems. While Adobe made the PDF specification available free of charge in 1993, PDF remained a proprietary format, controlled by Adobe, until it was officially released as an open standard on July 1, 2008, and published by the International Organization for Standardization as ISO In 2008, Adobe published a Public Patent License to ISO granting royalty-free rights for all patents owned by Adobe that are necessary to make, use, sell and distribute PDF compliant implementations. If there is a distinction that one should keep in mind regarding PDF and other formats, it is this: PDF is a standard which defines how renditions of data are to be made, such that they are universally consumable via Acrobat Reader, and can use all of the features of the standard which are unique amongst the various formats we are talking about, such as digital signatures, templates, forms, and rights management. PDF, in and of itself, does not define any 3D data format for representing manufactured products. Understanding how this came to be is our next discussion Background on U3D and PRC Since PDF does not itself define a 3D data standard, how does it manage to support 3D data? Here again, a short history lesson is valuable. In 2005, Adobe released support for 3D by referencing in the PDF standard, prior to its public release, an ECMA standard called Universal 3D, or U3D for short 1. U3D was a standard developed by an industry group called the 3D Industry Forum (3DIF), which included amongst its founding members both large companies such as Intel, Adobe and Boeing; as well as smaller companies such as Actify and others. U3D provides support for tessellated data only, product structure, animations, and textures. It does not however include support for such things as exact or BREP geometry and product manufacturing information. In 2006 Adobe acquired Trade and Technologies France (TTF), the developers of a digital mockup application called 3DReviewer. As part of the acquisition, Adobe obtained two other significant pieces of technology and intellectual property. These constituted a set of libraries which allowed a large number of data formats, including the major MBD applications such as Catia, NX, and ProEngineer, to be imported into a format called Product Representation Compact (PRC) 2. PRC provides support for both exact geometry and tessellated data, product structure, and product manufacturing information. PRC is in the final stages of becoming an international standard in its own right, expected to be completed in the first part of Both U3D and PRC are specified by the ISO32000 standard, and are fully supported by the Acrobat platform

12 The Data Exchange, Visualization, and Publishing Processes using 3DPDF By now it should be clear that what sets 3DPDF apart from other formats is its unique ability to create rich renditions of all kinds of data, including in addition to what is represented in the way of 3D information, such data types as 2D drawings, audio, video, animations and images Figure 5 - Using PRC to Publish to 3DPDF all encapsulated in a ubiquitously consumable form that includes forms, templates, digital rights management and signatures. A very key point in addition to the ubiquity factor is the presence in virtually any organization of the infrastructure necessary to properly support the generation, delivery, consumption, and management of PDF documents. After all, it is used in every functional area of the company beyond engineering and manufacturing finance, human resources, purchasing, marketing and sales to name a few. Figure 5 describes that publishing process (for the purposed of clarity only, we are using PRC to illustrate; the process using U3D is exactly the same). When it comes to the use cases for 3DPDF, note that for the purposes of comparing and contrasting PDF with formats such as STEP and JT, it should be clear that when discussing 3D data and its associated elements such as product structure and product manufacturing information, that it is the U3D or PRC data which is serving the purpose of exchange and visualization where the rich data making up a rendition is not required or desired. In such cases, PRC can be used without any involvement or employment of PDF as its own international standard, it can stand on its own, and from a functional perspective, is positioned very similarly to JT. The option exists however to use PDF as a transport container to get PRC data through an exchange process or to a specialized visualization app, thereby leveraging the relevant infrastructure. This is yet 12

13 another one of the very compelling benefits of adding support for 3DPDF to an organizations infrastructure stack. Publishing with 3DPDF in Detail Since as we ve defined it, publishing as an activity cannot be accomplished with STEP or JT (except in cases where data defined in either format is placed inside a PDF file for the purposes of exchange and can t be visualized), explaining what s involved in the process of publishing a PDF file containing 3D data in either U3D or PRC format will be useful. The diagram in Figure 7 shows the workflow involved in this process. As was mentioned previously, one of the distinct advantages of using PDF for publishing rich renditions of product data that are specific to certain use cases. Examples of such use cases are: Shop floor work instructions Inspection instructions and documentation Assembly instructions Maintenance and service Interactive catalogs Training documentation Request for Quote Technical data packages Direct consumption Derivative Format Consumer (via Acrobat Reader) MBD/MBE data Represents data authority MBD/MBE Authoring Application U3D for faceted geometric representation PRC for tessellated or exact representation XML representation of prodcut structure and PMI information Combines multiformat information Containes U3D or PRC without transformation Publishing Application Digital work instructions Sales after service information Compliance documents Archival quality Ubiquitous consumption Transformation Rendition Figure 6 - Detailed Publishing Process using 3DPDF Here again, there are advantages to adopting 3DPDF that are not present when using JT or STEP: 13

14 Publishing is an established process in most, if not all organizations; adding 3D support leverages those processes and associated investment The ubiquity of Acrobat Reader on almost any device delivers the potential of consumption without barriers; proprietary clients and controls for Office applications have significant issues with enterprise support and security Renditions tailored to specific use cases, along with ubiquity, assures maximum ROI through common use by combing 3D data with virtually any other form of data needed to fulfil the purpose of the rendition The pervasiveness of PDF has fostered the creation over many years of a rich ecosystem of tool providers, educational organizations, and subject matter experts 14

15 Summary The goal of this paper was to assist the reader in understanding how to answer the following question: If I already use STEP or JT, why should I consider using 3DPDF? The following points are components of the answer to that question: STEP is a highly verbose format which encapsulates all information necessary to define a product, its manufacture, and lifecycle support, independent of any authoring application, and is used almost exclusively for data exchange between MBD/MBE applications, and archival purposes. JT is format which facilitates the exchange and visualization of product definition geometry, product structure, product manufacturing information, and limited attributes; and is used both as a vehicle to exchange and visualize data between organizations, but also between applications within the various Siemens PLM Software products 3DPDF is a format for the exchange, visualization, and publishing of rich renditions of multiple types of data, by leveraging the combination of 3D data, either U3D or PRC, to describe of product definition geometry, product structure, product manufacturing information, and limited attributes Unlike 3DPDF, which can serve multiple purposes, STEP and JT are not capable of supporting the publishing activity which leverages 3D data downstream throughout the product lifecycle to create, distribute and manage ubiquitous, highly consumable, role-specific rich renditions for maximum ROI. Some final summary thoughts in conclusion: 3DPDF is a fundamentally different kind of tool than any PLM tool or component it is extremely agile, whereas they are not (understandably so). MBE is all about leveraging an investment in MBD to realize ROI deeper into the organization; however, if there is no or limited ability to consume the data, there is no (or limited) ROI Consumption of MBD data downstream is a function of agility and fit for purpose, yes, but the biggest barrier is ubiquity and price to consume. Ubiquitous consumption via Adobe Reader, along with the multi-data type architecture, place 3DPDF in category of its own For more information, or to find out who is supporting the 3DPDF community, please visit the 3DPDF Consortium s website at or send an to info@3dpdfconsortium.org 15