Product development is becoming increasingly global and as a result, new challenges have emerged, such as coordinating geographically dispersed teams of suppliers and partners. Consequently, the modern enterprise is more similar to a network of interconnected nodes that work in parallel and need constant dynamic synchronization. The widespread adoption of digital design documents, the introduction of collaboration tools like Web-based review and mark-up, and Internet-accessible databases have made design data more readily available.

However, the stages of the design process are still often like insulated islands of concentrated knowledge. Knowledge is communicated in the final format through rigidly managed, one-way transactions (e.g. check-in/check-out from a Product Data Management system) in which the work product is relayed to the next team at the end stage, rather than through a continuous, multi-directional, and synchronized communications process.

It is then easy to understand why loss of information is common and how inconsistencies continue to make collaboration a challenging process. Additionally, the cost of rapidly evaluating design alternatives and the inability to efficiently communicate design changes hampers innovation. To address these problems, a novel approach to collaboration that enables true simultaneous product development is beginning to take hold among engineers in the design industry.

Simultaneous product development is based on the premise that specialists from every area should be able to directly contribute to product design as early and as frequently as possible. These experts should also have the ability to interact with any detail of the product. They should have the tools to reconcile the product into the final specifications, and keep a record of the several paths and variants.

The characteristics of true simultaneous product development that set it apart from conventional collaborative approaches are:

  • It can be synchronous and asynchronous
  • It has no pre-defined granularity level on the data
  • It is independent from the sequence (history) or the timing of the design operations
  • It is independent from the flow direction of data.
Figure 1. An Engineer’s Model as it is being worked on, shared, and merged with team members.
Figure 2. The Industrial Designer’s View of the model under the same circumstances as in Figure 1.

In synchronous collaboration, all the members are logged on at the same time, while in an asynchronous session, members work off-line until they are ready to share their work. In both methods, the traditional collaboration tools have a serial way of proceeding: one member at a time on one pre-defined set of data at a time (usually a file) or in rotating control of markup tools. In contrast, simultaneous product development allows project members to work on the product model concurrently and then broadcast (share) and reconcile (merge) the changes with everybody else simultaneously if they work synchronously — in different times if they work asynchronously. In both cases, the result is the same:the contributions of all parties are automatically reconciled. Simultaneous product development is based on sharing and merging any element of a digital model and thus is not constrained, as in the parametric approach, by a pre-defined granularity level of data. This is very important because the traditional collaboration granularity is usually at the file level only. The same model encapsulates the functions of several disciplines and several bodies of an assembly will share the same interfacing objects. Object level granularity also means that it is possible to define project roles and design responsibility with unprecedented flexibility.

History independence of the modeling operations, another characteristic of simultaneous product development, requires a fundamental shift in solid modeling technology and migration away from feature-based parametric modeling. Rigidly organized, parametric modeling scarcely allows for a different timing or unforeseen changes in specifications, a potential result of simultaneous contributions from team members.

The key element to achieve history independence and break down the final barriers to true collaboration left unsolved by the parametric approach is the introduction of functional modeling, based on the functional object representation theory. The idea is to provide designers with functional features that encapsulate a behavior, rather than bundles of geometry that relate to each other like nodes in a network. The synthesis of such a network produces the required geometry and topology as the output of a set of functional specifications that are not dependent on the timing of their initiation.

A simple example is that of a hole. In feature-based design, the configuration depends on the location and nature of the form features that follow it in the model history. For instance, the addition of an extrusion at a later step may well change the depth of the hole or even eliminate its presence from the final boundary, whereas a functional hole has a well-defined semantic in mechanical design and its presence in the behavioral network of the model always has the same outcome. An interesting consequence of the functional modeling approach is that due to the built-in intelligence of the functional features, all the geometric details of each feature are not necessary to define the final body. Therefore, the size of the functional objects is relatively small and ideal for supporting collaboration for sharing and merging design changes even on limited bandwidth. Another important benefit of simultaneous product development is that it allows collaborative data to flow in any direction. Within a functional modeling design environment, each design object — from entire portions of a model to a simple point — can be "extracted" (shared) from the model of a collaborative session and "installed" (merged) into a different model at any time.

The shared object will simply merge and influence the final shape based on its behavior. There is no link maintained between the shared objects other than an identity card used to track the path and the changes. As a consequence, objects may be shared between collaborative teams in any direction and be modified and shared again by anybody. There is no concept of a "master model" or hierarchical organization among files where any modification requires well-organized file versioning and change propagation even if it is just an exploratory design variation. Designers truly free from the limitations of serial tools or hierarchical product structures can effectively support any methodology through all the stages of the collaborative design process, from the chaotic stage of preliminary brainstorming, where ideas flow freely without any particular structure, to the more organized phase where the specifications are consolidated and the design solutions narrowed down to a few. The final result is a more creative and intuitive design process that fosters greater innovation across globally distributed product development teams.

This article was written by Gian Paolo Bassi, Vice President of ImpactXoft, San Jose, CA. He can be reached at This email address is being protected from spambots. You need JavaScript enabled to view it.