What designers should know about history-based and "dynamic" schemes
CAD software with what is called a history-based approach to design has topped the field in market share since PTC Corp., Needham, Mass., introduced Pro/ Engineer in the late 1980s. About a year ago, CoCreate Software Inc., Ft. Collins, Colo., started pushing an alternative approach to 3D product development it calls " Dynamic Modeling." This is a proprietary term intended to stress the dynamic that is, fast and flexible design the company says its OneSpace Designer Modeling software provides by letting users directly push and pull models to make changes any time during the design process. But terminology brings a potential for confusion. The CAD industry in general uses the term "explicit modeling" to describe methods of directly editing the model. For clarity, it's easier to simply categorize the two approaches as "history based" and "history free."
Currently, the gray area between the two is larger than in the past. That's because history-based systems are increasingly adding local direct-editing operations. Yet, at their heart, each approach is unique, and each targets certain products and 3D product-development processes.
Another term crops up when discussing CAD systems: Hybrid modelers are those that handle surfaces and solids in the same environment. It's possible to find examples of both hybrid and solid modelers that use history and history-free methods. For example, Pro/E and SolidWorks are history-based hybrid modelers, while OneSpace Design Modeling has a history-free approach. Examples of other such systems, which represent a variety of solid, hybrid, and surface modelers, include KeyCreator, IronCAD, Alias, and Rhino.
HISTORY-BASED CAD SYSTEMS
As a quick review, here is how history-based CAD systems work:
First, it's helpful to understand the lingo, most of which comes from PTC. According to President of Product Management Mike Campbell, "Pro/E introduced the notion of a feature-based ' parametric' system. This means subsequent geometry is built upon and references geometry behind it. All geometries are controlled by parameters, which comprise constraints and relationships. Constraints are variables such as part dimensions and equations. Relationships, on the other hand, involve how PTC defines the concept 'design intent.' A history-based CAD system is said to capture an original user's design intent because the software remembers and enforces relationships between objects the designer generated on the screen."
As a user works, the software builds a feature history tree, which tracks all relationships and parameters and stores the order in which users create features. The tree effectively serves as a part "recipe." Changing a step and replaying the recipe forces associations in the history tree to ripple through the model and " regenerate" the new part. Once a part is built, users need only type in variables to change a preprogrammed model.
According to COO Robert Bean of Kubotek USA, Marlborough, Mass., which provides KeyCreator, "A good way to understand history-based design intent is with a concrete example. For instance, a designer might specify that a hole in a block must be centered. He locates it from a corner one-half the width and one-half the height of the block. So no matter what variables operators then type in, once the history recipe gets replayed, the hole gets put right in the center." History-based models are often called "intelligent" because they encapsulate this design intent.
Well-thought-out models are reliable, but the process of designing them can be usefully compared to building a house of cards. In this analogy, the "cards" would be modeling features that are interrelated in the history tree. When an original designer predicts future changes and designs the model with them in mind, it's not a problem to later rearrange a card or pull one out to modify the model. But without such design foresight, pulling a card would affect relationships to such a point where the model is no longer stable and would fail to regenerate.
It's important to note that history-based CAD systems are proprietary. Thus, difficulties can arise when importing nonnative files from any other system. According to CoCreate Senior Product Manager David Szostak, " Operators often tune-down model accuracy or geometry resolution to improve regeneration success. But lower-accuracy models do not always play well during import. For example, an imported model might not be watertight, that is, its vertices, edges, and faces do not line up and connect correctly." History-based systems can import and work with history-free files. In these cases, operators would only be able to append to the geometry, which basically starts a history tree from the beginning.
HISTORY-FREE CAD SYSTEMS
And here is how history-free CAD systems work:
Basically, an operator builds all components, parts, and assemblies in one common workspace. Multiple parts and assemblies can be loaded at the same time and a single command lets users arrange parts in a subassembly or move subassemblies within a top-level assembly.
Some history-free systems have users constructing models from fully rendered 3D shapes by dragging and dropping them from libraries. In other systems, designers sketch and extrude 2D profiles, similar to history-based CAD software. Users then perform local warping, scaling, and Boolean operations on the 3D geometry. Boolean operations attach or "union" shapes and "subtract" material by punching it out. Because designers build models in a way resembling how they would mold physical structures in the real world, history-free CAD systems are often compared to working with lumps of "digital clay."
After operators create geometry, they can add fillets and perform standard commands such as Shell. Changing the size of a piece of geometry is a matter of pulling and pushing on attached handles and editing fillets and tapers. When users remove a feature, the model heals itself.
Consider the block example above. According to Bean, "Again, assume a block with a hole in it that must remain centered. Since the model contains no intelligence, when a user adds, say 10 in. to the side and 15 in. to the top, the hole is no longer centered. In a history-free system, the hole is considered a cylindrical face. The user selects the face and tells the software where to move it by typing in delta X and delta Y."
Operators can center the hole, but it takes a few more steps.
Instead of a history tree, historyfree systems use an assembly-structure browser that displays a BOM, or list of parts and assemblies the designer has built. When a new part is created, its default location is at the top level of the browser. To place a part in an assembly, a user drags the part's position in the browser to a different location. According to Szostak, "Though there is no history tree, designers can add relationships and constraints to models by performing operations analogous to adding bullet points or formatting text in Microsoft Word. In Word, for example, a user goes to the Font menu and selects Make Bold. Similarly, when designers make a component longer, for instance, they select a face intersecting the component, go the 3D Modify menu, and select Move. Again, Word users can cut and paste text to move it. To extend the analogy, history-free systems let users cut, or punch-out, material and paste, or union, it to different model geometries."
The difference between the two approaches boils down to how design intent is defined. According to Szostak, "For CoCreate, design intent is not about relationships and constraints captured in a history-tree recipe. Rather, we say design intent involves having a final product be exactly as a designer intended. This entails the ability to respond to all the unexpected changes that happen throughout the discovery process of new product development."
BEST TOOL FOR THE JOB
Most companies have multiple CAD systems because they are trying to use the best tool for the job. And individual preferences often dictate which one a designer likes best. Yet a consensus says history-based systems usually target products involving large families of similar parts in which, say, only sizes or lengths change. And history-free systems are said to best fit in well in R&D environments and conceptual and manufacturing stages of design.
According to Campbell, "History-based systems have been successful in the marketplace because they let users modify designs in a highly predictable way. Many of our customers say that 70, 80, or even 90% of a new product is simply reused components. Take as an example a company developing an engine block. Once a valve is modeled, for instance, users can tweak sketches or parameters and generate a new valve with ease. For companies committing and documenting a design, a system with built-in design intent that has logic about how modifications are propagated makes subsequent reuse fast, efficient, and reliable."
Also, a bigger marketplace means lots of users and available hardware. History-based systems, therefore, might prove to be better tools in moving from design to design-through-analysis because the developers have such a large array of partners that designers can choose from.
"The differences between the two was a greater concern when history-based systems first come on the market," says Campbell. "Then, a historybased system was more complicated to learn and took more training. However, today's systems are simpler to use. And the market has proven there is good value in an investment of time, planning, and intelligence."
History-free systems, on the other hand, can be more effective in the early stages of design. According to Szostak, "Designers can capture and present design ideas to clients on-the-spot because they needn't think about the process of modeling. Instead, they can focus solely on the designs they are trying to create. Designers can, for instance, quickly generate 100 ideas and throw away 95 of them without investing a lot of energy in the model. Yet this ease-of-use doesn't preclude companies from designing complex products such as printer/copiers, some with over 35,000 different parts."
Lastly, Bean says history-free modelers are good when committing a design to manufacture. "At the manufacturing stage, shops often don't get the design history but need to leverage designs from many different CAD systems. For a similar reason, history-free software is useful at the back end, where it gives shops the flexibility to work with supply-chain mold, die, and designer shops."
A reader remarked "I enjoyed your article in Machine Design but I am wondering if you can answer a question about non-history based modelers. In your example of a simple plastic housing you do a sketch, extrude, blend and shell. This is the same as a history based modeler. Now, in a history modeler the wall thickness in the corners is maintained because the blends are above the shell operation in the history tree. How does a non-history modeler prevent the system from assuming that the shell command comes first and then would limit the size of the allowable radius based on the stability of the model.
Computers are very linear and regardless of whether a history tree is visible the operations have to be conducted one at a time - do the non-history modelers just run operations in random order until they get something stable or is there actually a history record that the user just can't edit. Either way I would be concerned that the model would be unstable as complexity increases.
Any light you can shed on this would be appreciated."
Todd Black from CoCreate Software Inc. responds:
We are glad to see readers are interested in the differences between history-based and Dynamic Modeling-based approaches to 3D product development. Rather than trying to describe the differences in a letter, we thought it best to simply show how a history-free system easily responds to changes with an online video. Click here to see the video.