Collaborating in a mixed
Selection of standards
A major goal of Opendesign.org is to provide a framework for
diverse individuals to collaborate on design projects. We want the barriers
to entry be very low. Inevitably, however, one of the first problems which
will arise is what development environment to use. This is the same problem
faced by any design project, the only difference is that the individuals
are not working for the same company with the same level of available resources.
Ideally everyone would have access to one particular very highend solid
modeling package. This is not possible. The same is true for every aspect
of the project from analysis to documentation. This document is an attempt
to outline the basic procedures for approaching this problem.
In general there are two conflicting needs. That
of accessibility and that of capability. If we pick the lowest common denominator
then everyone who wants to will be able to participate. But at the cost
of inhibited the design performance. If the highend is only selected then
only those who have access can contribute. This problem is particularly
compounded by market fragmentation in solid modeling. Thus, not only what
level but which package. CAD packages are for some reason a particularily
contentious subject for designers. Likely due to the large financial and
time commitments. Let us first explore how the CAD packages can be integrated
for a Opendesign.org project.
Working in a mixed CAD environment
Initially we recommend that a Master Modeler CAD (MMC)
package be selected for the project. This package should be of high enough
capability to complete the project. For example, if complex surfaces are
important to the project then it would not make sense to select an MMC
that doesn't support surface generation. It should be a package which the
project leaders and most of the sub-project leaders have access and strong
familiarity with. Beyond this it is preferably that the package run on
as many types platforms and OS's as possible, this makes it more widely
available. It should be stated, at this point, that FDF does not officially
support any particular package or environment.
Now that we have selected the package how do we
work? Let us first consider the simplest scenario. If we assume that the
selected CAD package is "A" then a designer who is also using that package
is in the best situation. The following figure illustrates how they would
interact with the data vault.
In the second scenario the users of a different solid
modeling package would need to access the models via a translation. Thus,
the data in the master model vault would have to be translated to a neutral
format, which we are recommending (for the time being) STEP. In a perfect
world we could just use STEP files (or some other format) for the master
model, thus eleminating the need for a MMC. For the time being this is
not feasible, but there are some potential emerging defacto standards which
may provide a superior future collaboration vehicle. For the time being
the translation from the master model to the STEP vault will need to happen
either automatically or manually, depending on the system setup. The user
of CAD system "B," the other solid modeling package(s), will interact with
the data vault as follows.
Because it is desirable to keep the native model information,
a special native vault is provided for model submission and maintenance.
A project leader who has access to CAD-A would then periodically update
the master model assembly with the updated geometry from the STEP vault.
The next level of user is the 2D CAD user (or even
a non-CAD designer). At this level the designer must interface with a collaborating
user who is either using the Master model CAD package (CAD-A) or another
solid modeling package (CAD-B). The 2D designer fetches drawings form the
dxf drawing vault. The collaborating user must then build or modify the
solids based on the 2D design work and then submit to the Data Vault for
the CAD-C user as shown below.
Comments on these web pages to firstname.lastname@example.org.
Copyright (C) 1999 to 2005.