Evan Yares highlights a productivity gap that CAD users have suffered from for the last two decades, exposes its source, and reviews the technology that will make it finally go away
For the last 20 years, parametric feature-based solid modelling has been the de facto standard for MCAD. Chances are that, if you read DEVELOP3D, you use (or have used) a CAD program that is based on parametric feature based modelling. And, if so, then you’ve experienced your share of frustrations with the technology.
It’s always possible to point out weaknesses in particular products, or failures in the areas of training or best practices when using CAD. Yet even in cases where best in class software is coupled with excellent training and best practices for use, there is a persistent gap between the theoretical productivity benefits offered by parametric CAD and the productivity benefits users realise from it in actual practice. In short, there’s a problem, and it’s not your fault.
To understand where the productivity gap comes from, we need to step back and look at the history of CAD.
The Dawn of Parametric Feature-Based Modelling
The vast majority of significant MCAD programs in use today trace their conceptual origins back to 1998, to the release of Pro/Engineer, the first commercially successful feature-based solid modelling system.
CoCreate. A mature non-history based CAD system that has gained inference capabilities over time
Other companies were working on similar systems at the time, yet Pro/E was notable in that it used parametric feature-based solids and NURBS surface mathematics. It also had a common data structure for all modules, including basic sketching, feature-based modelling, assembly modelling, drawing generation surface geometry and data management.
Pro/E introduced the common work process for solid modelling: draw a 2D sketch, add geometric constraints to it, and then convert it into a solid geometric feature using one of several basic operations. Subsequent sketches could be used to add or subtract additional features to the base model. Pro/E would record all operations, including sketches, constraints and feature creation, in a ‘history tree’.
‘It’s always possible to point out weaknesses in particular products, or failures in the areas of training or best practices when using CAD’
Sam Geisberg, the founder of PTC, said of Pro/E, “The goal is to create a system that would be flexible enough to encourage the engineer to easily consider a variety of designs. And the cost of making design changes ought to be as close to zero as possible. In addition, the traditional CAD/CAM software of the time unrealistically restricted low-cost changes to only the very front end of the design-engineering process.”
Like most new technologies, Pro/E had some flaws out of the chute. Yet the product was impressive enough that it forced competitors, such as SDRC, Unigraphics, ComputerVision and Dassault, to deliver similar capabilities. And it became a prototype for new generation lower-cost CAD products, such as SolidWorks, Solid Edge and Inventor. Ten years after the introduction of Pro/E, its competitors were all conceptually more similar to Pro/E than different.
User Frustrations
New technologies often take a while to mature. CAD, complicated as it is, has taken a very long time. Consider that in 2007, 20 years after it first developed Pro/E, PTC still spent over $100 million on R&D on the product. Competitors spent commensurate amounts on their products. Yet even with this investment, there are two common frustrations repeated by users of almost all parametric feature-based modellers.
KeyCreator. Has strong support for STEP, model repair, model validation, with inference of common feature types. No history support
You must be an expert to modify an existing model, and models are inflexible, and as they become complex, they fail too easily after changes.
And, while there are things that can be done to reduce the occurrence of these frustrations, there are no universal solutions – if only because these are symptoms of a deeper problem.
The Nature of the Problem
It’s possible to understand the deeper problem with parametric feature-based modelling by considering two fundamental concepts. A process is ‘imperative’ if it describes a sequence of steps to reach an end state (the term ‘procedural’ is also used for this). A process is ‘declarative’ if it describes what the end state is.
Parametric feature-based modelling is, by its very nature, imperative. That is, it is based on a sequence of commands (the history tree) that change the state of the model. Little known to most users is that it’s typical for parametric feature-based modellers to use a LISP interpreter, buried in the program, to evaluate the history tree.
IronCAD. Supports drag-and-drop features, with limited inference on dumb models. Supports both history and non-history based modelling
The process of engineering, as practiced by humans, is primarily declarative, in that it describes what something ‘is’, and is secondarily imperative, in that the process of actually making something often requires a sequence of steps.
While this distinction between imperative and declarative may seem a little esoteric, what it does show is where parametric feature-based modelling works well (with the portion of the engineering process that is imperative), and where it does not work well (with the portion of the engineering process that is declarative).
Because the terms procedural and declarative also relate to forms of human memory, this distinction also provides an explanation of why some people are able to easily learn to use parametric feature-based CAD systems – it is because they have strong functioning procedural memory.
Typical solutions to the problem
It is ultimately the difference between the imperative nature of parametric feature-based CAD, and the declarative needs of the engineering process, that leads to the gap in practice between the theoretical productivity of the software and its actual productivity.
SpaceClaim. A clean-sheet program, supporting direct editing of dumb files, inference of most features, drag and drop editing, and a modern Vista-style interface. No history support
The only practical solution to closing this gap lies in adding declarative design capabilities to CAD software. Of course, it’s easier said than done. Here are some of the more common techniques:
Kludges. These are special commands that let users get around limitations that would otherwise prevent them from getting their work done
Special Modules. Extra-cost add-ons (often expensive), to support a particular type of declarative object
Wizards. These are canned procedures, which create a particular class of declarative object
Knowledge Management Languages. These are essentially powerful imperative languages, which run inside a CAD program, and which can be used to build canned programs representing declarative objects
Application Programming Interfaces. Software interfaces that let you use an external program (eg Excel, or a third-party program).
Towards a real solution
The problem with the typical solutions to the parametric productivity gap is that they most often just make the software more complicated. In a situation where all users are CAD specialists, that’s probably not a major problem. Yet, in a situation where a company would benefit from making it possible for smart engineers and designers to be productive with CAD software without needing to be specialists, extraneous CAD complexity is not really that good a thing in the long run.
Solid Edge/NX with Synchronous Technology. Probably the most extensive implementation of history/non-history, imperative/declarative modelling in mainstream CAD applications. Supporting persistent non-history based constraints – a first
The cleanest solution to the parametric productivity gap is to add declarative modelling/editing capabilities to a program. But clean does not mean easy. A number of CAD vendors have been working on this for several years. Interestingly, their solutions are, in essence, very similar: a combination of direct geometry editing (without reference to history), and local feature inference.
Towards the Future
For 20 years, CAD users benefited from the capabilities of parametric feature-based modelling, but were often frustrated by its limitations. A new class of capabilities, whether called direct, explicit, history free, synchronous or declarative, promises to change CAD from a tool for specialists to a tool that’s actually useful for normal (smart) people. Though the elements of the technology have been around in some form for a number of years, it is only in this year that companies such as PTC and Siemens, in delivering them in a mainstream guise, have raised their profile. Siemens, in particular, has raised the bar by adding support for constraints (including parametric dimensions) without requiring history.
Evan Yares is a writer, consultant, analyst and user advocate, focusing on engineering software. His blog is found at www.evanyares.com. He gives Al Dean a run for the scariest man in CAD – and wins every time. His thanks go to David Weisberg, author of The Engineering Design Revolution, The People, Companies and Computer Systems That Changed Forever the Practice of Engineering, available online at www.cadhistory.net, for providing a reliable historical reference to the CAD industry.
Parametric feature based modelling has problems, we find the technology to solve them
