Leslie Gordon
Senior Editor
Imagine you work for a
smaller manufacturer
that decides to digitize
its product-development
process to make it more
efficient. To keep costs
down, the company
wants to use a standard,
open language that
anyone can edit instead of expensive proprietary
interfaces. The facility has been
keeping track of products it makes with
a relational database containing a lot of
tables with records of each part. Records
include individual fields that might hold
important design and manufacturing data
such as Dept., ID, Name, CAD Title, Material,
and Size.
Yes, you could put the database tables
into HTML for viewing the product information
on a browser. The problem is,
HTML basically just tells content how to
display. Thus, you might get nice-looking
tables, but you lose all the relationships
between fields that were established and
enforced by the database structure. This
would hinder attempts to automate processes
because computers would have no
way to efficiently search for information.
But there is a way to digitize this information
and maintain the relationships: use
XML. It provides a highly defined way to
automate the transfer of BOMs, assembly
instructions, engineering definitions, manufacturing
information, and so on, downstream.
The use of XML is transparent to
most designers. However, it can be helpful
to understand how XML portrays CAD data
in digital product pipelines. One interesting
question that arises is exactly how granular
XML gets when handling CAD files.
CAD data-structures
“CAD files process engineering information
and are highly compressed, while XML
is intended for exchanging text and being
descriptive,” says Peter Velikin, director
product marketing, PTC, Needham, Mass.
“CAD data structures could be broken
down into XML, but this would be inefficient.
For one thing, tags would take up too
much space. And because CAD files are binary,
XML would force software to process
them in a trial-and-error way that would be
too slow. A CAD program such as Pro/Engineer,
instead, directly specifies, or links
to, binary-file offsets, so it quickly jumps to
the byte where the next step would be.”
Velikin says a good use of XML is in the
exchange of complete CAD files. For example,
XML might carry structural, property, tabular, and manufacturing data about an application
component (part, drawing, or assembly) as
well as information such as version number, recipient,
and department. A combination of XML
data and tessellated geometry (for the display of 3D
components) or vector data (for the display of 2D
data) in a container such as a ZIP file completes the
CAD-file definition.
Velikin says PTC believes strongly that XML is
great at automating how design information gets
represented to end users, important because CAD
files alone are sometimes not sufficient to understand
design intent. So, the developer’s Arbortext
dynamic-publishing package lets users associate
documents to product design, database, and business
systems containing records for products, parts,
and assemblies. Users can create or reuse existing
text, illustrations, and animations derived from, and
linked to, CAD files. XML ensures that documents
get automatically configured and published in the
right format and language, on the media of choice
(Web, CD, print).
Dynamic linking to databases ensures documents
automatically update when relevant data
changes, says Velikin. Thus, the correct design,
manufacturing, operating, and service information
gets delivered to all intended recipients, regardless
of geographic location or level of expertise.
When it comes to manufacturing, Velikin says there is currently an initiative called STEPml, a collection
of XML specifications based on product-data
schemas from the widely known STEP standard. In
addition to manufacturing, STEP schemas control
processes such as analysis, engineering, and supply-
chain management.
An advantage of using XML over STEP or IGES is it
allows efficient exchange over the Web, says Velikin.
“Product teams need not have a particular CAD
program to view files. Another advantage is XML
enforces strict adherence to the standard and so
provides an efficient communication mechanism.
It uses what are called document-type definitions
(DTD), sort of like “blueprints” that define and impose
constraints. A movement is afoot in the publishing
community to standardize how companies
that customize their XML implementations would
refer to a common source. I’m not aware this has yet
happened for data exchange, but I’m sure it eventually
will.”
Model-based definitions
Most packages predate a lot of the efforts in XML,
so CAD kernels are not set-up to store information
that way, says John O’Connor, director of product
and market strategy, Vistagy Inc., Waltham, Mass.
The company provides specialized engineering software
for the design and manufacture of airframes, transportation seating, and components made from
composites. He says where XML shines is in letting
users add more details and data to geometric models
and then share this information to anyone on the
team in any format.
“For example, our EnCapta program ties into existing
PDA and PLM databases while working inside
CAD packages such as Catia, Pro/E, and Unigraphics.
Users can author applications in XML to capture
information and store it in models that thereby
provide a truly complete 3D product definition.
The software houses this information in XML and
shares it downstream in any format, or for any PLM,
PDM, ERP system,” says O’Connor. “The software
even lets users associate nongeometric data that’s
in XML to a particular portion of geometry (for example,
a point or a line) in CAD models.”
He says XML’s capabilities come in handy for
composite design because a lot of nongeometric
information must be captured to fully and accurately
describe parts. It also supports new forms
of manufacturing such as forming and stamping
composites.
“A designer of military jets uses an EnCapta application
to deliver model-based definitions to the
shop floor that contain all data in a 3D environment,” says O’Connor. “This reduces the need for 2D drawings,
while the structured nature of XML allows the
automated generation of 3D supplier bid-packages.
This has saved the company a lot of money.”
A GUI on top of XML
Unlike previous programs mentioned, Seemage
software from Seemage, Newton, Mass., is not CAD.
Basically it is a GUI on top of XML that uses existing
CAD PLM data to generate 3D documents and
animations for collaboration, markup, training, assembly
instructions, and the like.
“Packages that don’t use XML provide proprietary
interfaces for associativity,” says CEO Chris
Williams. “This means companies wanting to combine
data from different PDM and CAD systems and
maintain associativity between them bear the burden
of integration. But what makes for a difficult
problem in proprietary systems becomes simple in
XML-based ones.”
According to Williams, files in the software contain
named objects and links to geometries, for example
on a server at particular addresses. Using everything
with a different geometry is just a matter of changing
the link because of the open nature of XML.
“Users can get geometry and metadata separately,
or merged together in what we call an SMG
file,” says Williams. “The software includes converters
that translate, say, Pro/E files to SMGs. These are
stored in an XML fashion so users can programmatically
edit them.”
He explains the software is fundamentally a property
manager and includes about 500 properties
including color, material, revision, version, name,
position, and piece of geometry. The authoring program
lets users store these properties in an XML
document type definition.
“A manufacturer might use the software to generate
3D geometry characterizations for 3D search,”
says Williams. “Firms often want to link to STEP files
for manufacturing. Aerospace concerns such as
Airbus also use a format called VML for technical illustration,
which is an offshoot of XML 1.0. It defines
a format for encoding vector information together
with additional markup to describe how that information
displays.
Make Contact
PTC, ptc.com
Seemage, seemage.com
Vistagy, vistagy.com
Comparing XML with HTML
In HTML, special code called an
element comprises markup tags
that contain content and tell a
browser how to display it. For example,
consider a database table
to be put into HTML. Data about
each product type (say, antennas)
is contained in rows made up of
individual fields such as ID, Name,
Material, and Size. HTML turns the
relationships between these enforced
by the database structure
into just raw pieces of text with
formatting instructions around it.
The tags <tr> </tr> and <td> </td>
merely tell the content to display
as columns and rows in a table:
<tr colspan=”4”>
<td>3954</td>
<td>FM Antenna</td>
<td>Aluminum</td>
<td>5 ft</td>
</tr>
In contrast, XML uses tags that
name the content they display.
They use the same field names
as found in the database and
thus keeps the relational structure
intact:
<Antenna>
<ID>3954</ID>
<Name>FM Antenna</Name>
<Material>Aluminum</Material>
<Size>5 ft</Size>
</Antenna> |
A PDF of a digital
plybook page used
in the manufacture
of a composite
aircraft part shows
design details
including ply
number, material,
and orientation.
The details
were stored in
Vistagy’s FiberSIM
software, which
automated their
export into the
PDF document
via XML. The
language also
allowed sharing
the associated
CAD model
to improve
engineering
collaboration and
reduce errors in
manufacturing.
Seemage Publisher uses XML to manage all information
about the assembly.
A “dynamic” document created with PTCs Arbortext XML authoring and
publishing software links to a database or business system containing the
records for the product, part, or assembly. Documents thus update every time
design data, manufacturing data, or CAD files are changed.