Technical Data Packages: Choosing a Path JT or 3D PDF
Say you want to drive somewhere and have a choice between two roads: One is well-paved and takes you halfway to your destination, but you may have to pay a lot of tolls along the way, while the other is under construction, yet will take you exactly where you want to go. Which road do you choose? Unfortunately, this is the position many companies find themselves in today with regard to technical data packages (TDP) as they try to decide how to best create content utilizing Model Based Definitions (MBD) in a Model Based Enterprise (MBE).
Today Technical Data Packages are likely based on templates that pull information from sources such as part files, the PDM (product data management) system, and other databases. When not in a Model Based Enterprise, this is 1D or 2D data that typically goes into a PDF file either directly or as part of a process that generates PDF from a document format like Excel or Word. What is missing is the 3D model and a relationship between the 3D data and other data in the package. Adobe’s 3D PDF file seems like the right choice to support a Model Based Enterprise Technical Data Package, given that PDF is already part of the solution and allows 3D data to be translated into the native PDF file format. You could even add a STEP file as an attachment to the package if you want to include additional geometry data. So what’s wrong with that approach?
A process such as this creates a number of derived formats and incurs translations that all must be validated and—in the case of a STEP attachment—managed after they are created. 3D PDF will also add JavaScript data to the 3D PDF that can present security concerns in some workflows. If your company has a Teamcenter PLM system today, you already have the 3D data necessary for a TDP as 3D JT data.
JT is an ISO standard for visualization and collaboration. It is a global standard for the automotive industry and has been broadly adopted in heavy machinery, transportation, consumer products and, increasingly, the aerospace and ship building industries. Generally, all workflows for creation of TDP will be run from the PLM system. Wouldn’t it make sense to use existing 3D JT data and not have to translate geometry, PMI, Model Views etc., as the Model Based Design data for the technical data package? What is missing is a way to connect JT data to the PDF document along with a way to navigate within them. JT plus PDF using JT2Go provides this capability.
Currently, Siemens does not offer out of the box solutions to generate Technical Data Package from templates for First Article Inspection, Work Instructions, Assembly Instructions, etc. This is what we mean when we compare JT to a road that is under construction.
The battle for the de facto model-based definition 3D data representation will be waged for years to come. While there is a lot of buzz today around 3D PDF, particularly in the aerospace industry, many overlook the costs—both financial and process—to starting down that path. 3D PDF ultimately will create another derived 3D model of engineering data. JT should be the obvious choice for customers using Teamcenter or NX. If your company uses Teamcenter, you are already creating (and hopefully validating) JT for visualization. Validation of the 3D data is required. JT is a better format for 3D visualization; it is the choice between 100% accuracy all of the time or just 99% accuracy. Do you really want to risk being inaccurate 1% of the time?
If companies want 3D PDF content, they must accept that there will be translation errors. This comes with a cost—both in time and money—to find and fix those PRC translation issues that result. Many consider the benefit of 3D PDF to be the viewing window on the first page of the PDF. However, this requires the user to continually scroll back to the beginning of the PDF to see the 3D geometry. It is a much more elegant solution to have two applications, i.e. PDF and JT2Go.
JT plus PDF
JT plus PDF is a simple approach to creating a 3D Technical Data Package without creating any new derived 3D data. The JT file is simply attached to a standard PDF file, and then specific content in the JT file is linked to the PDF through an easily understood URI protocol. JT2Go makes it easy to generate URI strings either interactively or programmatically. If a PDF file with URI links is created manually using Word or Excel , JT2Go provides a command to attach the visible JT file to a PDF for free. In fact, JT2Go allows any JT file to be attached to any PDF file. JT2Go can be used to load the PDF file directly or the PDF can be loaded into Acrobat Viewer and the JT in a separate JT2Go session. JT2Go listens for the URI selections and reacts to the specified commands. Anyone can download JT2Go from www.jt2go.com today and try this out directly. The short side of this story is that Siemens does not currently provide a means to auto generate JT plus PDF from any products out of the box today. This situation will be changing though, and tools are available from Siemens to perform automated generation using Teamcenter Visualization’s Automation offering. For more information check the presentation given this year at the JT International conference hosted by Microsoft in Redmond, Washington.
A question I often get from those who work in aerospace is, “Why doesn’t NX provide a simple 3D PDF export from NX like some other CAD tools?” As an NX product manager, I’ve considered proposing a “tick in the box” solution like some CAD tools have done.Some CAD tools offer an Export 3D PDF in their product for years and when I ask NX customers, what if NX implemented a simple solution like this, would this satisfy you? They always say, “No”. Does this capability progress you toward your goal? “No”.
Customers are really looking for a Model Based Definition Technical Data Package solution. MBD requires a templates and pulls information from the part file and the PDM system and even other disparate databases like SAP. Customers want a true Model Based Enterprise system with Teamcenter as the backbone.
Benefits of PDF +JT
Currently not all companies accept JT as a model definition standard. The ISO standard for JT is for visualization only, but hopefully the JT OPEN community is still making progress eliminating the “for visualization only” statement in the ISO standard verbiage. Many companies that sat on the committee that helped define STEP as a neutral file format standard, it is now hard for them to suddenly say JT is a right solution. Further STEP supports some things that JT does not (e.g. composite layout definition), so there are some functional gaps with JT. The same argument for JT as the neutral file format exists. Using JT avoid translation issues, while STEP will require some level of validation and repair.
For many customers, they envision a utopia using JT in PDF as the visualization AND model definition as the ultimate solution. Unfortunately, it seems there is little opportunity for support here. If a company wants to use 3D PDF, there is nothing that prohibits companies from creating 3D PDF and using an embedded JT file. In fact, one customer sent me a 3D PDF that contained the hyper-links to JT2Go. The only real argument a company could say about the why they would rather use 3D PDF vs. JT + PDF is the desire to have a zero download solution (in reality, though, PDF is also a download, yet is pervasive enough to meet the criteria of zero download).
While the tools to develop a solution for sharing 3D data downstream using PDF+JT are very compelling, currently an out of the box solution does not exist. Third party CAD tools offer an initial solution that satisfies some initial requirements for individual components, but these solutions are not considered scalable and are difficult and costly to maintain. So what are companies going to do? They can either pay a lot of money for an initial solution that does not enable the customer to ever achieve their vision, or develop their own solution based on best practices using JT? While it is not ideal that an out of the box solution is not available yet, many companies are of the belief that taking the easy wrong road which leads to a dead end is worse than taking the more challenging road that, while still under construction, gets you where you want to be. We agree it is preferable.
About the Author:
Derek England serves as the product manager for NX Design focused on the Aerospace and Defense industry. Derek joined Siemens in 1997 supporting the sales team mentoring customers, performing product demonstrations and benchmarks. Currently, Derek works within NX development as the NX product manager for Aerospace and Defense Design, ensuring NX is optimized for aerospace and defense design workflows.
