NISTIR 7796 

Model Based Engineering 

Standardization and Validation 

Joshua Lubell 

Nathan W. Hartman 

Doug Cheney 
NISTIR 7796 

Model Based Engineering 

Standardization and Validation 

Joshua Lubell 

Engineering Laboratory 

National Institute of Standards and Technology 

Nathan W. Hartman 

Purdue University 

Doug Cheney 

ITI Transcendata 

July 6, 2011 

U.S. Department of Commerce 

Gary Locke, Secretary 

National Institute of Standards and Technology 

Patrick D. Gallagher, Director 
1 

MODEL BASED ENGINEERING STANDARDIZATION AND VALIDATION 

Joshua Lubell 

National Institute of Standards 

and Technology 

Gaithersburg MD, USA 

lubell@nist.gov 

Nathan W. Hartman 

Purdue University 

West Lafayette IN, USA 

nhartman@purdue.edu 

Doug Cheney 

ITI TranscenData 

Milford OH, USA 

Doug.Cheney@transcendata.com 

ABSTRACT 

3D Model-Based Engineering (MBE) is an approach to 

product design, manufacturing, and support where a digital 

three-dimensional representation of the product serves as the 

normative source for information communicated throughout the 

product’s lifecycle and supply chain. MBE simplifies data 

management and provides a more powerful communication 

medium than 2D-based environments. Lightweight formats, 

offering a low-cost way for humans to view and potentially for 

applications to consume geometry and Product Manufacturing 

Information (PMI), are a critical component of MBE and 

enable collaboration without requiring that business partners 

buy expensive Computer-aided Design (CAD) systems. These 

formats are becoming increasingly popular – and increasingly 

complex – as their representational capabilities grow. Their 

value to industry is driving a push for standardization. We 

discuss the advent of MBE, the standards and technologies that 

make it possible, and the importance – and challenges – of 

product data validation. 

NOMENCLATURE 

ASME American Society of Mechanical Engineers 

CAD Computer-aided Design 

CAM Computer-aided Manufacturing 

GD&T Geometric Dimensioning and Tolerancing 

MBE Model-based Engineering 

PDF Portable Document Format 

PRC Product Representation Compact 

PLM Product Lifecycle Management 

PMI Product Manufacturing Information 

STEP Standard for the Exchange of Product Model 

 Data 

U3D Universal 3D 

VDA German Association of the Automotive 

Industry 

VRML Virtual Reality Modeling Language 

3D MBE AND VISUALIZATION TECHNOLOGY 

3D Model-Based Engineering (MBE) is an approach to 

product design, manufacturing, and support where a digital 

three-dimensional representation of the product serves as the 

normative source for information communicated throughout the 

product’s lifecycle and supply chain. [1] In MBE, the “model” 

serves as a container not only of nominal geometry information 

but also of Product Manufacturing Information (PMI) as well as 

supplementary notes, reports, multimedia, and any other digital 

data useful for documenting the product. 

While products with relatively short lifecycles may not 

have a need for maintaining data for extended periods of time, 

the aerospace and defense sectors have vehicle and weapons 

programs that have lifecycles measured in decades. These 

industry sectors are also two of the most dependent users of 

Product Lifecycle Management (PLM) technologies and 

processes, which by nature promote the use of a 3D modelbased environment and are the most likely to benefit from using 

it. [2][3] 

As an example of a 3D model consider Figure 1, an Adobe 

Reader1

 screen shot (downloaded from 

www.adobe.com/manufacturing/3dpdfsamples/3dsolutions) of 

a bracket part visualization created from a native Computeraided Design (CAD) model. There are several points worth 

mentioning about this example. 

 The visualization can be rotated and otherwise manipulated 

to maximize understanding by humans. However, it is not 

intended for exchange between CAD systems. It 

complements rather than replaces the original CAD model. 

 The image has PMI callouts, using the standard syntax to 

specify geometric dimensioning and tolerancing (GD&T) 

annotations. Even though the visualization lacks the full 

semantics of the original CAD model, it is helpful in 

communicating to humans how to manufacture the part – 

arguably more so than an annotated 2D drawing would be. 

 The callout at the top of the figure is unstructured text. 

This is also part of the product data. In fact, product data 

can include arbitrary attachments such as spreadsheets 

containing analysis results, video data, and other associated 

information relevant to the product. These attachments are 

important and need to be managed and monitored, even if 

CAD and CAM systems do not “understand” their data 

formats. 

 1

 Mention of commercial products or services in this paper does not imply 

approval or endorsement by the authors or their employers, nor does it imply 

that such products or services are necessarily the best available for the purpose. 
2 

Figure 1. 3D visualization of a bracket part with PMI. 

PMI is a particularly critical constituent of MBE. Loosely 

defined, PMI can include any sort of information defining a 

product’s components for manufacturing, inspection and 

sustainment. PMI includes geometric dimensions and 

tolerances (GD&T), as well as material specifications and other 

annotations, specified in a formal language whose syntax and 

semantics are defined in several American Society of 

Mechanical Engineers (ASME) and International Organization 

for Standardization (ISO) standards. PMI is essential to 

developing complete product data. Manufacturing cannot take 

place without it. Therefore, MBE requires not only the ability to 

edit and display PMI, but also the ability to feed GD&T 

semantics to computer-aided manufacturing (CAM) systems 

and other downstream applications. [4] 

MBE is appealing to industry for a number of reasons. 

 Having a single, normative information source makes data 

management easier. With the model as master, the model 

effectively serves as a centralized database such that all 

information presented to humans or fed to other 

applications/processes is generated from the model. This is 

analogous to a report being generated on demand from a 

database. Thus there is no need to archive or manage this 

generated information, unless it is directly used to satisfy 

legal requirements such as type design certification for an 

aircraft. 

 3D is superior to 2D for promoting understanding and ease 

of searching data. [5][6] This is particularly true for 

younger engineers, who are accustomed to information 

being presented as 3D graphics. But there is a caveat. 

Information overload reduces understandability, so user 

interfaces must be able to provide for layering and/or 

selective hiding of the graphics. 

 Recent advances in visualization technology (discussed 

below) and the availability of low-cost software now make 

it feasible for product designers to share both precise 

geometry and PMI with suppliers, machine shops, and 

other collaborators – without requiring that the 

collaborators buy expensive CAD systems. 

 Not only does MBE enable information sharing, but it also 

supports access control to proprietary or sensitive data. 

Information may be selectively extracted from the model 

as needed, depending on the recipient’s “need to know.” 

For example a CAM system needs PMI in order to 

manufacture a part but does not require knowledge of how 

the design was created. Therefore, it is appropriate that the 

information sent to the CAM system include precise 

geometry and PMI but not include any procedural 

information or parametric data. 
3 

ISO 10303 – also known as STEP (Standard for the 

Exchange of Product Model Data) – provides a neutral, nonproprietary way to represent 3D geometry and PMI. [7][8][9] 

STEP is useful in MBE both as a means of exchanging models 

between CAD systems and as a means of archiving models. But 

the need to communicate models to people who are not 

designers and applications other than CAD systems has grown. 

As a result, visualization technologies such as JT [10] – a data 

format developed by Siemens PLM Software – and PRC [11] 

(Product Representation Compact) – an Adobe format for 

embedding 3D data in a PDF [12] file – are becoming 

increasingly important. In fact, some visualization file formats 

are undergoing standardization as discussed later in this paper. 

Visualization technology is an enabler for communications 

in the modern product design, manufacturing and support 

environments. Historically, the use of drawings for humanconsumable information was the conduit for information 

exchange. Designers used drawings to communicate design 

intent, manufacturing engineers used drawings to plan 

assembly processes, and service and support technicians used 

drawings to maintain and support a product in the field. As the 

digital backbone that supports the modern product data 

enterprise has been propagated throughout the extended product 

lifecycle, an obvious medium of communication has evolved – 

the lightweight visualization format and its associated viewing 

technology. 

The use of lightweight collaborative formats derived from 

fully-featured CAD models offers a low-cost way of viewing 

and consuming geometry and PMI information. Costs are 

reduced in areas such as the number of full CAD licenses 

necessary within a corporation, the time spent trying to 

leverage fully associative CAD models in areas where it is 

unnecessary, and the reduced time to communicate product 

information and model metadata throughout the lifecycle given 

the use of web-based delivery and authoring mechanisms. 

Through the use of web-based components in the lightweight 

formats, collaboration is arguably much easier. The file formats 

are smaller, the viewing utilities work well in the web-based 

environment, and a sophisticated training regimen is not 

required to use the visualization formats or their viewers. 

In addition to supporting collaboration, these formats make 

it easier to consume design and manufacturing information in 

other parts of the lifecycle. Viewing tools are more efficient and 

use less systems resources than do full CAD platforms, 

reducing the overall software costs for a corporation and 

making it easier to implement low cost hardware for those 

people who do not require as much computing resources. These 

data formats are also suitable for the mobile computing 

environment because of their relatively low computing 

overhead and the inclusion of web-friendly elements within 

their file definition. Both mobile devices and low-cost network 

computing technology are used by more people than ever 

before, which offers companies an opportunity to deploy 

visualization technology more widely. Another aspect of these 

formats that promotes collaboration is their robust 

mathematical definition compared to their relatively small file 

size. A precise data representation without the impact of large 

file sizes allows these formats to be used for data archival, 

manufacturing inspection, supplier collaboration and other 

areas where moving data efficiently and accurately is 

important. 

VALIDATION AND MODEL CONSISTENCY 

What truly constitutes the 3D product definition? Is it the 

CAD database only? Is it the model plus drawings? Does it 

include analysis results? One of the fundamental requirements 

of a functionally complete MBE environment is that a fullydefined, fully-annotated 3D CAD model be the master source 

of product definition information. While this may not be a 

reality today, technology is moving in the direction to enable 

such an environment, driven by the need for both human and 

machine consumption of model data. In recent years, leading 

aerospace and automotive manufacturers have implemented 

MBE and thereby motivated the technology maturation 

necessary for other companies to follow suit. 

In order to manage a product’s lifecycle, one must manage 

the data lifecycle that accompanies it. One area where this is 

evident is the format in which product data is shared. In order 

for MBE to be effective, a digital definition of the product must 

exist that is correct, complete, and unambiguous. Authorized, 

equivalent derivative forms of the master data must be 

generated to support the user’s task at hand without losing the 

embedded sophistication and richness of the original product 

definition. Nowhere is this more obvious than in the use of 

lightweight collaborative formats throughout various industry 

sectors today. While the underlying technology driving these 

formats has been available for many years, it has only been 

within the last five years when the use of these data formats has 

begun to take shape in a way as to predict future direction. 

What is meant by “lightweight collaborative format?” 

According to Ding et. al., [13] lightweight formats arose out of 

the need for enhanced communication and collaboration 

between distributed design teams without the overhead 

associated with using the native CAD models. In addition, 

viewing and manipulation of non-native CAD data, file size 

implications of native CAD data, incompatibility between 

native CAD formats, and the protection of intellectual property 

are all issues that have given rise to the use of the lightweight 

collaborative formats in various stages of the product lifecycle. 

[14][15] While the differences between lightweight 

collaborative formats can be substantial, the nature of their use 

is beginning to converge in areas outside of the typical 

visualization realm. These formats were originally meant to 

communicate visual information for human consumption, such 

as part identification or component fit within the larger 

assembly. This was due in large part to the inherent imprecision 

of their geometric definition of the object as it was derived 

from the CAD model. This also allowed the file size of these 
4 

formats to remain relatively low when compared to the native 

CAD model or to the common STEP format. 

However, as the technology providers began to enable 

more robust and precise geometric definitions of the product 

within the collaborative formats, users began to implement 

them in other workflows within the organization and their file 

size began to grow. This change in use and file size has now led 

to the collaborative formats being used to exchange data 

between original equipment manufacturers and suppliers, 

finished inspection within a manufacturing environment, and 

the creation of 3D technical publications and data packages to 

support entire product programs. [16] Using collaborative 

formats in this way has also increased their file size due to the 

necessary product geometric definition and metadata that needs 

to be carried forward, and it has blurred the line between bona 

fide standard formats and the contemporary collaborative 

formats (especially as some of these formats are currently 

undergoing ISO standardization). Industry now finds itself in a 

scenario where collaborative formats are being used in the same 

manner as native CAD or STEP formats, necessitating the 

development and implementation of a data validation scheme to 

ensure the product data survives the translation process. 

Thus product data validation is a critical component of 

MBE. If the model is to be the master representation of the 

product, from which all others are derived, then it had better be 

accurate, precise, and unambiguous. And all derivative 

representations must have those same characteristics if they are 

to be trusted when used outside of the engineering context and 

the native CAD model representation. The risk of different 

definitions and interpretations of PMI is much higher than for 

geometry – which is why validation of collaborative formats is 

receiving more attention within MBE than for older geometryonly processes. 

In a drawing-based environment, the drawing itself 

(particularly when paper-based) contains the relevant product 

data and serves as a trusted information source for those using 

it. When drawings are shared, there is typically little worry 

about information being lost due to translation error in the 

medium. 

MBE, however, provides multiple ways in which to share 

product data, but – given the slightly different means by which 

various software tools define geometry – translation between 

software applications is a challenge. It is these slight 

differences that account for most (if not all) of our current data 

translation errors, hence the need for validation. If companies 

are to maximize benefits from their CAD data assets, they must 

be able to trust their data as correct, complete and unambiguous 

for indefinite periods of time regardless of authoring software 

version or translator used. 

OBSERVATIONS AND ISSUES 

To further understand the overall challenges of MBE 

standardization and validation, we examine them in the context 

of the following issues that arise in the representation of digital 

product data. 

Parametric and Procedural Information 

Our discussion so far has emphasized integration of 

engineering design with downstream functions such as 

manufacturing or field support. A different scenario is when a 

design needs to be edited in multiple CAD systems. This may 

be required when design groups use different CAD software 

collaborate or when, due to business mergers, acquisitions, 

partnerships, etc., the design authority migrates between 

dissimilar systems. Both cases require not only the exchange of 

precise geometry data but also of design intent, i.e., information 

about the design process itself. Design intent information 

generated by CAD systems includes procedures used to create 

shape models, parameters bound to values in the model, 

constraints between parameters and/or model elements, and 

features – the shape “building blocks” used to construct the 

model. Without design intent, a model cannot be easily edited. 

[17][18] This is because the precise geometry shows only the 

final result and says nothing about the steps that got you there. 

A good analogy – given in [17] and illustrated in Figure 2 – is 

the representation of a chess game. A board diagram is a 

“precise” model in that it gives a comprehensive view of the 

current state of the game. But it lacks information regarding the 

sequence of moves leading up to the current state. In order to 

refine a design – or fine-tune a chess playing strategy – one 

needs that procedural information. 

Figure 2. Precise and procedural depictions of a chess game. 

From [17]. 

Although CAD systems generate this procedural 

information, visualization formats do not include it. But, in 

scenarios where visualization technology is enjoying great 

popularity, this is a feature and not a bug. Companies often 

want to share 3D models with partners or customers without 

giving them the ability to reproduce them in an editable or 

modifiable form. And CAD vendors can provide tools allowing 

their customers to convert models to visualizations knowing 

that their customers cannot use the visualization as a means for 

migration of their data to a competing software vendor’s CAD 

offering. 
5 

Until recently, no standard existed for exchanging design 

intent. Today the second edition of STEP AP203 [9] supports 

some design intent, as does the latest version AP214. [8] But so 

far no CAD vendors have implemented this functionality. 

Document versus Model 

The model as master is a primary tenet of MBE. But sometimes 

a document-centric metaphor is more useful. For many actors 

in a product’s lifecycle, a written report is the clearest form of 

communication. Also, MBE may be the ideal but not the reality 

– an engineering process may require drawings that have yet to 

be replaced by models. In situation such as these, a paradigm 

where the document is paramount – and models are attachments 

to (or embedded in) documents rather than the other way 

around – may be a better fit. Also, some product definition 

metadata is best communicated in document form as a 

complement to the master model definition, rather than forcefitting it into a 3D model format. 

The PDF standard (ISO 32000) [12] is particularly well 

suited for document-centric engineering processes. The PDF 

format is essentially a packaging mechanism for whatever 

formats one wants to exchange with collaborators. Thus a PDF 

instance can include reports, multimedia, drawings, and of 

course 3D visualizations. For example, the image shown in 

Figure 1 was captured from a PDF document including video, a 

spreadsheet, etc. The PDF specification is agnostic regarding 

which of an instance’s constituent parts – if any – is the 

“master.” 

Evolving Technology 

MBE technology continues to evolve. CAD/CAM vendors 

have implemented the first generation of PMI presentation and 

semantics standards, and the STEP, JT, and PRC specifications 

are being revised to support exchange of PMI graphics and 

semantics (structured data). As a result, design systems have a 

greater ability than ever before to offer information to 

manufacturing systems, and manufacturing systems are better 

able to consume that information. However, successful 

integration of design and manufacturing systems requires not 

only the existence of exchange standards, but also requires 

standards for interoperability testing and technology 

implementing those standards. 

The ISO TC213 and ASME working groups responsible 

for PMI presentation and semantics have recently released new 

versions of the PMI standards increasing their complexity and 

representational richness by an order of magnitude. This will 

drive a new cycle of innovation in CAD/CAM software, which 

will in turn lead to revisions of CAD data exchange standards 

to “catch up” with the software vendors. 

The evolution of the technology underlying the data 

formats used in documenting the product lifecycle makes it a 

challenge to select and implement a specific format. [14][15] It 

is nearly impossible to know for sure whether the data source 

and the data destination will remain congruent in perpetuity. In 

MBE, the 3D digital product definition is the conduit by which 

various stages of the product lifecycle communicate with each 

other. Incompatibility between native CAD data formats makes 

this communication difficult, leading to the need for validation 

of 3D product definitions as explained later in this paper. 

Supplemental Geometry and Advanced PMI 

ASME Y14.41, a national standard for PMI presentation in 

3D models, defines supplemental geometry as “Geometric 

elements included in product definition data to communicate 

design requirements but not intended to represent a portion of 

the manufactured product.” [19] Examples of supplemental 

geometry elements include cutting planes, center lines, and 

Cartesian points. Supplemental geometry is a critical 

component of MBE for two reasons. [20] 

1. PMI can refer to supplemental geometry elements. Thus, 

without supplemental geometry, PMI is of limited use. 

2. Automated machining and inspection processes require 

tool target information, which in turn requires 

supplemental geometry. 

Clearly it is important that supplemental geometry be 

successfully transmitted from CAD models to downstream 

processes. However, recent results testing model translation 

between CAD systems using JT as an exchange format [21] are 

cause for concern. Conducted jointly by the ProSTEP 

consortium (http://www.prostep.org) and the German 

Association of the Automotive Industry (VDA - 

http://www.vda.de), the tests indicate a high success rate 

translating precise geometry and PMI graphics but less success 

translating supplemental geometry and PMI semantics. As 

Figure 3 shows, information for human consumption was 

translated more reliably than information for machine 

consumption. Another way to interpret the results is that the 

more “semantic” the information, the less successful the 

translation. 

Figure 3. Translation success between CAD systems, using 

JT as an intermediary. 

The ProSTEP/VDA report does not elaborate on the source 

of translation problems, i.e., whether the cause is due to JT 

export from the originating CAD system, JT import to the 
6 

destination CAD system, or issues with the JT format itself. 

Nevertheless, the report shows areas where improved CAD 

translation is needed and also shows how the growing usage 

and capabilities of JT and other lightweight formats add to the 

challenges of interoperability testing. The primary challenge is 

to properly organize and document the intent of this 

information in the master model, and then to accurately 

translate this into the various derivative formats required for 

downstream consumption. 

Evolving Definition of “PMI” 

Most downstream tools and processes supporting 3D 

annotations today are simply displaying this data for human 

consumption as they have been doing with 2D drawings for 

many years. Thus the technology focus has been on ways to 

place planar annotation symbology in the space around the 3D 

model geometry. To avoid the “fur ball” effect (i.e., information 

overload), authoring and viewing applications support “saved 

views” (also known as captures, combined states, or model 

views) defining a camera position, zoom level and visibility of 

annotation and geometry entities. The human user then 

activates the display of each saved view to aid in understanding 

the data. 

Some manufacturing and inspection technologies are now 

being upgraded to directly consume the annotation data 

directly, without regard for how it is displayed graphically. 

They require a complete semantic definition of each PMI 

construct, including each data element and the precise 

relationships with the model geometry. For example, a 

geometric tolerance defining the positional variation of a 

pattern of holes can be visually defined with a few properly 

placed annotations: a feature control frame and multiplicity text 

note with leader line to one of the holes and one to three datum 

feature symbols attached to geometric entities defining the 

datum reference frame(s). A complete semantic definition 

requires clear identification of all geometry defining all holes in 

the pattern, the geometry for all aspects of the datum reference 

frames with explicit connections to the positional tolerance 

construct, and a “machine-interpretable” definition of each 

element (tolerance values, modifiers) which would otherwise 

be displayed in the feature control frame. 

As downstream processes increase their ability to consume 

PMI semantics, this in turn raises the bar for the level of 

semantic completeness required in the authoring and translation 

technologies. 

Standardization Issues 

What do we mean by a ‘‘standard’’ in the context of MBE? 

Such standards may be one of at least these types: [22] 

1. Open Standards relate to the general idea of 

interoperability and integration – an agreement that people 

make so that products and systems made by different 

parties can work together. Open standards are not software 

applications; they are only specifications explaining how 

information should look. Open standards are developed by 

consensus in an industry group. There is a tremendous 

variation in the membership rules and processes for these 

organizations, and they range from official organizations, 

such as ISO and ASME to vertical industry groups such as 

the Strategic Automotive product data Standards Industry 

Group (http://www.sasig.com). STEP is an example of an 

open standard. It is developed by ISO, with the help of 

industrial consortia, such as PDES, Inc. 

(http://pdesinc.aticorp.org) and ProSTEP. 

2. Industry Standards are technologies that are commonly 

used, but are not open or democratically managed by a 

group of users. The current JT file format specification is 

an example of an industry standard. There are a number of 

companies involved in the JT Open consortium 

(http://www.jtopen.com) but because one company wields 

a tremendous amount of control over the process, JT is 

classified as an industry standard, not an open standard. 

Standards address the changes in technology development 

and usage over time. For MBE, what is primarily at issue is the 

nature by which CAD software tools encode information when 

storing it in their native file format and when they export data 

into alternate formats. Some alternate formats are open 

standards (e.g., STEP and PDF), while others are industry 

standards (e.g., JT and PRC). In fact, the former are more like 

data models or wrappers for holding content than they are a true 

data format, while the latter are formats provided by a specific 

technology vendor, thus possessing proprietary characteristics. 

The proprietary nature of some collaborative formats makes it 

difficult to build process and other technologies around them 

due to the uncertainty over the long-term viability of the data. 

In addition, those collaborative formats that are 

transitioning from industry standards to open international 

standards are taking different paths to get there. The most 

notable example is Universal 3D (U3D), [23] an underlying 

geometry representation format for the 3D PDF technology and 

alternative to PRC, which is passing through the “documentcentric” ISO committee TC171/SC2. The JT format and others 

are passing through the more “product data-centric” ISO 

TC184/SC4 committee. While this may seem appropriate, and 

it may be, it raises a question about how product data is treated 

in the eyes of the international standards community – is it 

product data, or are all of these formats simply considered 

documents generated by the product lifecycle processes? The 

answer to that question has operational impacts both for 

technology providers and for companies that build their 

processes around this technology. A split in how these formats 

are handled within the larger international community could 

have impacts on how companies build processes around their 

use. In addition, it raises the question as to whether the notion 

of a document is comprehensive or specific enough to 

encompass all the requisite information generated during the 

product lifecycle. 
7 

Another issue regarding the progression of collaborative 

file formats from industry standards to open standards is 

whether the collaborative file formats as currently specified are 

“open” enough to meet the requirements of standards 

development organizations. A collaborative format may be 

optimized for a particular vendor’s software platform, at the 

expense of interoperability with competing vendors’ products. 

A benefit to having a format being recognized as an open 

standard is that specification of the format has been vetted by a 

committee where no single member has inordinate influence – 

at least in theory, thus giving users of the format some 

assurance that their validation tools and processes will remain 

viable. A key point to be mindful of is that most people in this 

data exchange and validation space see the ownership of a data 

format by a specific company as potentially detrimental with 

regard to long-term archival and accessibility of data encoded 

into such a format. Whereas, the maintenance (and long-term 

development and propagation) of a format by an international 

standards body is seen as a bit more palatable. 

LOOKING AHEAD 

As we look ahead to the future of communications within 

the product lifecycle, it is clear that the CAD model is changing 

from its historical role of documenting geometric definition to 

being the conduit for information exchange within multiple 

industrial processes and workflows. Technology providers are 

developing product definition tools beyond the scope of 

geometry to include textual and symbolic data that in the past 

would have been communicated via 2D drawings. As such, the 

user community must adapt its ways of working and knowing 

relative to this technology, while facing new standardization 

and validation complexities brought on by this brave new 

world. 

Product definition information taking a visual (or 

geometric) form is typically easy for a human to consume 

through the use of accepted practices and standard definitions 

of format. Older visualization technologies such as the Virtual 

Reality Modeling Language (VRML) [24] presented this 

information in a way that made this relatively easy to 

accomplish; however, they lacked much of the richness of 

meaning that today’s current and emerging product definition 

forms possess. The new formats being created approach 

communications from the point of representation, allowing for 

the possibility of product definition information to be not only 

human-consumable but also machine-consumable. 

However, clear and unambiguous encoding of the 

representation’s underlying semantics is a challenge. This is 

one of the driving reasons why process and data validation is 

extremely important in an MBE environment. Practical and 

effective validation must incorporate all types of digital product 

data and all formats the data may take throughout the product 

lifecycle. Companies must identify the key characteristics 

required to remain consistent while allowing other aspects of 

the digital definition to vary within acceptable limits, thus 

accommodating the inevitable differences between MBE 

technologies. 

As derivative formats have emerged from the native CAD 

dataset, they have transitioned from being used for visualization 

and simple communication between humans to being part of the 

process in long-term archival, machining operations, and 

quality control and inspection. They are also being used in 

marketing pieces and virtual environments where the native 

CAD database would have been used previously. These new 

uses often result in lower costs, increased geometric accuracy, 

and better communications for the users, but not without 

quality assurance of the translation between CAD systems and 

derivative formats. 

REFERENCES 

[1] “5 Secrets for Making the Model-Based Enterprise a 

Reality.” White paper from Renaissance Services. 2008. 

http://www.mbesecrets.com/

[2] Schmitt, P. (2007). PLM in aerospace: High-profile 

projects help extend PLM technology through the entire 

aerospace supply chain. Manufacturing Engineering, 

138(3). Retrieved from http://www.sme.org/cgi-bin/findarticles.pl?&ME07ART16&ME&20070311&&SME&

on January 18,2011. 

[3] Van Wijk, D. et. al. (2009). Integrated design and PLM 

applications in aeronautics product development. 

Proceedings of the 19th Annual CIRP Conference, 

Cranfield University, UK, March 30-31, 2009.

[4] V. Srinivasan. “STEP in the Context of Product Data 

Management.” In Advanced Design and Manufacturing 

Based on STEP. Xun Xu and Andrew Y.C. Nee eds. 

Springer London. doi: 10.1007/978-1-84882-739-4. 2009. 

Pages 353-381. 

[5] Theodore J. Branoff, Nathan W. Hartman, and Eric N. 

Wiebe. “Constraint-Based, Three-Dimensional Solid 

Modeling in an Introductory Engineering Graphics Course: 

Re-examining the Curriculum.” Engineering Design 

Graphics Journal. Volume 66. Number 1. Winter 2002. 

Pages 5-10. 

[6] S. K. Ong, M. A. Mannan, “Virtual reality simulations and 

animations in a web-based interactive manufacturing 

engineering module,” Computers & Education, Volume 43, 

Issue 4, December 2004, Pages 361-382. 

[7] ISO 10303-1. Industrial automation systems and 

integration – Product data representation and exchange – 

Part 1: Overview and fundamental principles. First edition 

1994-12-15. 

[8] ISO 10303-214:2010. Industrial automation systems and 

integration – Product data representation and exchange – 

Part 214: Application protocol: Core data for automotive 

mechanical design processes. 

[9] ISO 10303-203:2011. Industrial automation systems and 

integration – Product data representation and exchange – 

Part 203: Application protocol: Configuration controlled 

3D design of mechanical parts and assemblies. Edition 2. 
8 

[10]JT File Format Reference. Version 9.5. Rev-A. Siemens 

Product Lifecycle Management Software Inc. 2010. 

[11]PRC Format Specification. Version 8137. Adobe Systems 

Incorporated. 2008. 

[12]ISO 32000-1:2008. Document management – Portable 

document format – Part 1: PDF 1.7. 

[13]L. Ding, A. Ball, J. Matthews, C. McMahon, and M. Patel, 

“Product representation in lightweight formats for product 

lifecycle management (PLM),” presented at Fourth Int. 

Conf. on Digital Enterprise Technol., Bath, UK, Sept. 19-

21, 2007. 

[14]N.W. Hartman and M.A. Lim. (2008). Examining neutral 

formats for visualization and data exchange,” in Proc. of 

the 2008 IAJC-IJME Int. Conf., Nashville, TN, Nov. 18-

19, 2008. 

[15]N.W. Hartman (2009). Evaluating lightweight 3D graphics 

formats for product visualization and data exchange. 

Journal of Applied Science & Engineering Technology, Vol 

3, Retrieved from 

https://library.rit.edu/oajournals/index.php/jaset/article/vie

w/234/0. 

[16]A. Ball, L. Ding, and M. Patel. (2007). Lightweight 

formats for product model data exchange and preservation. 

Presented at PV 2007 Conference, Oberpfaffenhofen, 

Germany, Oct. 9-11, 2007. 

[17]Michael J. Pratt, Bill D. Anderson, Tony Ranger. “Towards 

the standardized exchange of parameterized feature-based 

CAD models.” Computer-Aided Design. Volume 37. Issue 

12. October 2005. Pages 1251-1265. ISSN 0010-4485. 

DOI: 10.1016/j.cad.2004.12.005. 

[18]Junhwan Kim, Michael J. Pratt, Raj G. Iyer, Ram D. 

Sriram, Standardized data exchange of CAD models with 

design intent, Computer-Aided Design, Volume 40, Issue 

7, Current State and Future of Product Data Technologies 

(PDT), July 2008, Pages 760-777, ISSN 0010-4485, DOI: 

10.1016/j.cad.2007.06.014. 

[19]ASME Y14.41, Digital product definition data practices, 

The American Society of Mechanical Engineers (2003). 

[20]Yochen Boy, Phil Rosche. “Recommended Practices for 

Supplemental Geometry.” CAx Implementor Forum. 

November 1, 2010. http://cax-if.org

[21]ProSTEP iViP/VDA. “JT Translator Benchmark.” Short 

Report. Edition 1. February 2010. http://www.prostep.org 

[22]Russell S. Peak, Joshua Lubell, Vijay Srinivasan, and 

Stephen C. Waterbury. “STEP, XML, and UML: 

Complementary Technologies.” J. Comput. Inf. Sci. Eng. 4, 

379 (2004). DOI:10.1115/1.1818683 

[23]Ecma International. Standard ECMA-363. Universal 3D 

File Format. 4th Edition. June 2007. 

[24]ISO/IEC 14772-1:1997. Information technology – 

Computer graphics and image processing – The Virtual 

Reality Modeling Language (VRML) – Part 1: Functional 

specification and UTF-8 encoding