Read Cad Guidebook: A Basic Manual for Understanding and Improving Computer-Aided Design Online
Authors: Stephen J. Schoonmaker
Tags: #Science & Math, #Biological Sciences, #Biotechnology, #Professional & Technical, #Medical eBooks, #Special Topics, #Professional Science
11.2.1 Files Management Versus Metadata
In 3-D CAD systems, the individual entities being tracked by the 3-D CAD data-
base manager software are mostly held in many individual operating system files.
For instance, 3-D part models are often PRT files, and 3-D assembly files are
often ASM files (these files would be specific to a particular CAD system—there
is currently no industry standard PRT or ASM file). The database manager soft-
ware, then, is going to at least need to control or “track” the location and disposi-
Managing 3-D CAD 265
tion of these files. This sort of information can be referred to as metadata
(meaning data about data).
Although it may be possible to just use an operating system’s file manager
as a control mechanism, this is not going to provide a good database management
environment. In this case, there is no separate database manager program or en-
gine; this can cause difficulties in managing the CAD data. For instance, if an
ASM file simply records the directories and file names of a list of PRT files that
are contained in an assembly model, but then these PRT files are renamed or
moved to another directory, the ASM file is going to be invalidated or corrupted.
It is far better to have a separate database (or table) recording the informa-
tion about the operating system files and locations. Now, a database manager pro-
gram can offer an option to move the PRT files to new directories, and the tables
can be updated accordingly to keep track of their locations. The ASM file would
simply refer to the tables to find out where the PRT files are located (using an
appropriate key or item ID scheme). The remainder of this section assumes that
this metadata database management approach is being used by the CAD system.
Keep in mind, though, that the database management scheme for the CAD sys-
tem may be based on a special database manager program developed by the CAD
system vendor, or it may be based on third-party database programming.
The location of operating system files is just one aspect of the kind of infor-
mation that can be tracked, controlled, secured, queried, etc. by the 3-D CAD
database manager software. Other kinds of information would be similar to the
information discussed for 2-D CAD management, such as drawing number or
part number, revision level, ECO number, etc. The 3-D model database would
also have part numbers, revision levels, and ECO numbers. But, databases for 3-
D CAD could also contain information on material properties (i.e. indicating if
parts are made of steel, aluminum, plastic, etc.), geometric properties (such as the
part being based on a family of parts or from a standard library of parts), and
feature properties (such as what manufacturing process is used for a particular
feature). The amount and type of this data that is available to be managed will
vary depending on the CAD system, but the more information that is controlled
by the database manager software, the more processes in the organization that
can be made to work together effectively.
11.2.2 Parent/Child Relationships
The hierarchical approach to database management where some items own other
items, or where one item is dependent on another item’s existence, is heavily
used by 3-D CAD system database management. There are two important
sources of this hierarchy data.
The first common source of these parent/child relationships is assembly
structure or BOM. The BOM is a listing of the items that are needed to create an
266 Chapter 11
assembly (refer to the chapter on assembly modeling). For example, a bicycle as-
sembly would need to have a number of parts brought together such as the frame,
tires, handlebars, nuts and bolts, etc. It is the BOM that lists each of these items
and how many of each item (or quantity) is needed. There is also usually a draw-
ing or 3-D model that shows exactly how the pieces are put together. Figure 10.11
shows how this product structure could be listed. The owning or parent assembly
is shown as indented to the left, and all the items within it are shown indented to
the right (to indicate that they are under or children of the parent assembly).
Clearly the BIKE_ASSY at the top of Figure 10.11 requires the exist-
ence of the parts listed within its BOM or assembly structure. In other words, if
the SEAT is a PRT file that is called out by or used by the BIKE_ASSY ASM
file, then this PRT file should not be deleted (unless the BIKE_ASSY is altered
to no longer need the seat). Also note that the bicycle assembly contains or
uses other assemblies (i.e. more ASM files); these are referred to as subassem-
blies. In Figure 10.11, CRANK_SUBASSY, FRONT_WHEEL_SUBASSY,
and REAR_WHEEL_SUBASSY would be called the subassemblies of the
BIKE_ASSY, and each of these subassemblies would typically be yet another
ASM file using their own PRT files having more parent/child relationships.
Virtually all manufacturing involves these parent/child relationships based
on BOMs. The network of relationships between the parts (or details), subassem-
blies, and top or final assemblies can become quite complex, and there may be
many levels of assembly structure. The 3-D CAD database manager software
needs to keep track of all these files that may be present and manage the relation-
ships between them (knowing which parts are used by which assemblies; know-
ing what parts are contained in each assembly).
The second common source of parent/child relationships in the 3-D CAD
database is associative 3-D models and 2-D drawings. With a 3-D CAD system,
drawings (or at least the geometric entities within drawings) can be automatically
generated by viewing the 3-D model. Subsequently, the 2-D geometric entities
(such as lines) are associated to 3-D geometric entities in the 3-D model (such as
surface edges). Now this means that the drawing (kept in a DWG file of some
sort) becomes a child of the 3-D model (a PRT or ASM file). The drawing is
dependent upon the existence of that particular 3-D model.
In order to manage these various parent/child relationship, the CAD data-
base manager software uses such devices as pointers, indexes, and relational da-
tabases to keep track of the data. The assembly model is going to have pointers to
the various part models that go into that BOM. Then, as the part model evolves,
the assembly model can easily show the changes since it is only pointing to the
part model (or some version of it). Of course, the same part model may be used in
more than one assembly model (for various products being designed), so the part
model may use its own system of pointers for its parent assemblies.
Managing 3-D CAD 267
11.2.3 “Where Used” Functionality
One of the most powerful uses of the parent/child relationship capability is the
“where used” functionality. This involves
determining how many times and in
how many ways a particular item has been referenced or used by various parent
or owning items. For instance, the TIRE indicated by the BOM in Figure 10.11
may be used in a variety of the products being manufactured by the company. In
fact, a “where used” query for that tire would indicate that it is at least found in
the front and rear wheel assemblies of the BIKE_ASSY. The 3-D CAD database
manager software should be able to readily provide this sort of information. In
some systems, this functionality may reside with PDM software (see Section
11.3.4 below on Product Data Management), but the concept is the same.
The “where used” functionality is important for designers to research how
changes to an item (such as a part) would affect the company’s various products.
Perhaps a part has been used as a standard part in many products, but now the
first product that used the part needs to be changed. All the reuses of the part, as
well as its original use, need to be checked so that the new part will fit in each
application.
11.2.4 Database Integrity
As the complexity of the network of relationships proliferates, the relationship
data may not be stored in just the ASM and PRT files, but rather in separate rela-
tional database files, or in some combination of files. For instance, it may be better
to record the BOM information in the system-wide databases instead of the indi-
vidual ASM files. Now the BOM data can be generated by simply querying the
database (and not having to scan the information in all the relevant ASM files).
Clearly an administrative issue that arises from this approach is database
integrity and/or synchronization. Any BOM-type of data in the ASM files will
now have to agree with the BOM data in the system-wide databases. Unfortu-
nately, the databases can become “corrupt” in some circumstances. For example,
when one computer on a network is attempting to record new database informa-
tion on the server, but it fails in the middle of the operation (network failure,
hardware failure, etc.), then the separate databases may not agree. The CAD sys-
tem or the database manager software should provide means to recover from
these situations. Of course, proper backup procedures are essential to database
recovery in some cases. All the CAD data files (PRT, ASM, DWG, DBF, etc.)
should be considered mission critical and backed up accordingly.
11.2.5 Version Management
Another issue to consider for how database management is somewhat unique
with 3-D CAD systems is version management. Many non-CAD databases or ta-
268 Chapter 11
bles are intended to contain only the latest and greatest information about a sub-
ject. As new data is created, then the database merely gets the new information
and removes old information.
However, design and engineering work has its own life cycle. The data is
typically tracked through phases such as conceptual design, detailed design, ap-
proval cycles, release to manufacturing, retention and long-term maintenance,
and destruction. Sometimes the current disposition of the engineering informa-
tion is dictated by the new product development process; sometimes it is dictated
by the manufacturing process; and, sometimes it is dictated by legal, liability, or
even statutory issues (where data must be carefully controlled and maintained
by law).
What this means is that even if a version of a 3-D model and its drawing is
wrong or has a mistake, it may be necessary to keep the incorrect drawing and the
metadata about that drawing for a long time. The product may have been manu-
factured with that mistake (hopefully not to the detriment of function and safety),
and copies of the product are now in the field. Thus, the incorrect drawing as well
as the corrected drawing should be kept on file (according to proper record reten-
tion policies) to support that fielded application.
Therefore, the database manager software needs to control not only the
records about specific items in the database files, but it needs to control versions
of the various items. It would normally present to the user the latest or up-to-date
version of items, but then it may also present the older versions. It may also need
to present the full history of the item (not to be confused with part history of part
modeling).
Beyond the support of item history for long-term product support, version
management is needed if parts are re-used in a number of different design
projects. For instance, if two different 3-D assembly models (such as a tricycle
and a bicycle) both use the same front wheel, and the front wheel is revised for
the benefit of the tricycle only, there may be a time when both the old and new
versions of the front wheel need to be supported (since the bicycle is still using
the older version). When a designer looks at the latest 3-D tricycle model, the
newer front wheel should be shown. But when another designer looks at the latest
3-D bicycle, the older front wheel should be shown.
Of course, there could also be interchangeability issues related to whether
the new front wheel could still function on the unchanged bicycle assembly. And,
there may be effectivity issues in terms of exactly when changes are rolled out to
the manufacturing process. So even in items that are revised in all parent assem-
blies (such as updating or regenerating the bicycle and the tricycle assemblies for
the change in the front wheel), the older versions may still need to be tracked
until the roll out of the new design to manufacturing is complete. These are all
scenarios that the 3-D CAD database system needs to be able to address.