When speaking about design processes using Computer-Aided Design (CAD) solutions, people often refer to “engineering intent.” Not being a CAD guy (and not playing one on TV either), I would ask colleagues about exactly what this meant. Most of the conversations left me confused, because they would talk about history trees, and the problems with one person having to make changes to another’s design and having to unravel the steps that were used to transform shapes into the desired part or assembly.
This left me believing that a lot of what people referred to as engineering intent was really “geometric intent,” the steps that a person executed using their CAD solution of choice to create the desired result. As a lapsed mathematician, I knew that there were many geometric ways to skin the cat, if you will. You can get to a desired geometric end result using different transformations. How you got there was a function of what ways your chosen CAD solution provided to you, and you knowledge of how best to use them. That is not to say that there is NO engineering intent in these steps, it was just that what I was hearing was more about geometry than engineering.
One explicit way that engineering intent does get into models is through parametrics. The requirements that engineers start with can often be expressed by mathematical relationships between faces or other features in the model. Another is what some term “design in context,” where there are contraints on your model that result from the other adjacent parts and assemblies into which your part must fit.
So why is this important, and why did I choose the title of a 90s “chick flick” for this post? Because in the last few years, several CAD suppliers have introduced solutions that make it easier to repurpose, modify, and otherwise change existing geometry. Siemens PLM Software talks about Synchronous Technology. SpaceClaim is making a business around helping people downstream from geometry creation to tweak things to make them easier to use (like CAE analysts or manufacturing people or people in supply chains).
It is this issue that raises serious questions for me. How can downstream users modify existing geometry and really KNOW they are not doing so in a way that affects the true engineering intent? You can’t really embed all of that intent in the model, and downstream people may not know about the real requirements. If your analysis reveals a weakness in the structure, and the analyst can change that structure, how can you be sure that the resulting part still meets the original spec? This example is not so bad, because if they are in the same organization you can have it kick off an engineering change process to make
sure this happens.
But what about people outside your four walls and not so clearly under your control? Contract manufacturing organizations for instance. The results of such downstream changes could indeed be cruel to your organization. (Not sure that Reese, Ryan and Selma thought about this one.)
OK, if anybody is still listening, please explain to me the error of my ways. I look forward to the discussion.
This reminds me of a talk I heard a while back from one of the original founders of NASTRAN (I think that’s who said it). In talking about product design he said that when we talk about design we’re really talking about geometric design when what we really need to be talking about is functional design. As a CFD guy, this rang true with me
In other words, we should design things for the aero or thermal or structural or electromagnetic performance first, then shape them.
I realize it’s not that simple.
Getting back to your article, design intent to me means “why is that part shaped that way.” It has nothing to do with feature trees. It has nothing to do with geometry. Design intent is “the wing is shaped that way so it doesn’t bend too much in a 9G turn” or whatever.
Or here’s another way to look at it. By the time an analyst gets geometry it’s a real mess. For an aircraft you’ll have tens or hundreds of thousands of bits of geometry. Design intent (aka engineering intent) is knowing which 2,000 surfaces are the wing or the tail or whatever. When you have to do loads accounting by geometry component, part of the analysis burden is recovering the geometry lost in the CAD.
One might conclude that I’m arguing for the integration of CAD and analysis. While there are definite benefits for doing so (the elimination of CAD interoperability problems one of them) there’s still a place for best-in-class CAE methods separate from the CAD.
Don’t know whether this was the commentary you were seeking. I should also learn not to post while watching a movie on TV.
Well Stan, since you opened up this can of worms, here is my 2 cents worth. And I am an old CAD guy!
You are correct that most people confuse geometry creation with design intent. This may have come about because of the use of the word “history” when describing the CAD operations tree. However, as you point out, history and intent are two quite different issues and many histories can be applied to creating a design to fit a required intent. By way of example, a number of years ago a group of designers for a very large company that I won’t name performed an experiment using a modern CAD solution (also unnamed). Being curious about history-based CAD, they decided to discover how different designers would use the same CAD tool to create a very well specified mechanical assembly. They presented a group of designers experienced in their CAD tool of choice with detailed specifications, waited a while, then collected the completed designs. When they examined the history trees embedded in the various designs, they found just what you might expect—no two of them were alike, not even close. But, they all implemented the vast majority of the initial specifications, the intent.
Now for a short digression into the diabolical minds of the perpetrators of this experiment. They then gave each of the designers a design created by someone else in the group. No one was given his own design. Then they provided specifications for some changes to be made to the design. Only one designer was able to execute the complete set of required changes. A couple of others were able to make some of the changes, and a few were not able to make the changes at all. Which illustrates the basic issue with trying to live in a CAD history based design environment. The history that one person creates may be complete gibberish to another person.
Now to get back to the intent of your blog post, which is that design intent is more important than design history. The ugly problem is posed by the question: How can you capture design intent? Certainly parametric information and contextual design help, but, unfortunately they do not today, and I suggest they will not in the future, be able to capture all of the intent. For this, something other than CAD is needed.
This leads us to PLM. There are numerous solutions centered on the PLM concept. In this case, the primary issue is to be able to document and capture the intent of designs. Requirements management is as good a starting point for this today. It allows the design specifications to be enumerated and associatively linked to features of the geometric model. Thus, they can be monitored and validated as the design evolves. This is critical because, if a feature of the design is modified, it is imperative that the designer checks that the change does not invalidate any associated specification. Likewise, if a requirement changes, then it is critical that the impact on the geometric design is well understood and appropriate changes are made to accommodate the modified specification.
Much more could be added on this topic. Additions and comments are welcome.
John MacKrell, CIMdata
Gee I had always figured you for just another CAD guy… You are 110% right, the CAD system does not capture design intent. At best the CAD model will have some geometric parameterization if the users understood the drivers and built the model in this way… which has led to the creation of non history based CAD tools.
The real “Design Intent” is buried in all the emails flying about that are used to solve design issues and support design tasks. “True Design Intent” can be found in all the interaction between the people who resolve the things being tracked on the project issue list. Just look at what happens when a team is changing a part that was designed a few years back. They start asking around to see who was involved and then asking those people, if they are still there and they can remember, what drove the design, what problems they had?
One would hope the PLM and PDM tools have this data, but they do not. These tools are great at capturing the version of a file, but these tools have no idea what happened or why the part was changed or who was involved in the decisions during the change. The FDA has created a process that force design teams to manage what they call the Design History File. In short – This file is suppose to tell the FDA what decisions were made and who was involved and did the change modify the intent of the product. If you look at a DHF you will find things like issue lists, email and all sorts of unstructured information. At Vuuch we are calling this an items social life-cycle.
If the PLM, PDM and ERP tools know what a part is at version A or B then the social life-cycle knows what happened between A and B. So what is this social life-cycle? Take a very simple situation where a designer is working to resolve an issue on a part and they need to bring the vendor, manufacturing and purchasing into a discussion to come up with a resolution… The PLM, PDM and ERP system will not know about this chain of people, but a Social Enterprise System used to manage the design issue will not only know about all these people it will also know their contribution.
This is exactly what Vuuch does.
http://www.vuuch.com/plm/social-life-cycle-andor-a-system-of-record/2011/06/07
Stan, in my view design/engineering intent is outside of CAD/PDM/PLM systems. All these systems are just capturing information related to the “intent”. People in an organization (on the individual and group level) keep some records of the intent. Fundamentally, people capture their intents with some record systems. Even revision management system can capture some level of intent (i.e. Why the change was done?). People may capture an intent different depends on the system they have. Valid points mentioned by John – related requirement management (part of the intent) as well as communication and emails mentioned by Chris. However, the real intent is on the individual (or group) level. It is the answer on the question “why it was done this way”. 20-25 years ago people talked about Knowledge Management. Fortunately, these days everybody understood the level of dreams in this domain. Capturing information about what happens in an organization, design changes and many others can help us to reproduce the design (or engineering) intent. Just my thoughts.. Best, Oleg
Interesting. The fact that engineering intent existed well before CAD, PLM or any of the systems in use today, I thought would be a pretty big hint.
@Craig – yes of course it did exist. So do you think that the term has just been appropriated and misapplied?
@John – Yes PLM has been part of the solution. One problem has been making it easy for engineers and others to capture, and then recall that information. That leads to…
@Chris – Thanks Chris. We got a briefing on Vuuch a while back and I look forward to catching up soon. I think that you guys are working on stuff that does fit right in here, and are working at a good level of integration. This is better in many ways than what people have been doing with tools like DOORS, and others. It also covers the ideation/evolution process better on how engineers are collaborating to meet that elusive intent. I look forward to hear more from your customers on how well users are taking to your approach.
Stan,
You raise some good points. In a geometry only system, it is almost meaningless to speak about design intent or engineering intent. Without the ability to express constraints, relationships, capacities at the level of material properties, engineering units and requirements, we do not have the language sufficient to express intent. This takes the term beyond what is possible today in a CAD system alone.
I would argue further that the need to enforce intent in an engineering model precludes interaction, otherwise expressing such intent is documentation and borders on being barely a suggestion. This takes the term out of what is possible in in a PLM system alone.
Consequently, I believe the term is only useful in the context or producing and evaluating designs automatically; in a design automation system with its own engineering model and language with the constructs required to both describe intent and, if we want any confidence that it is correct, produce a design.