Top-Down Design Methods

My last post here talked about Top-Down Design – a big selling point for some CAD software – actually turning out to be a best-practice nightmare. And it is. Besides that, it’s kind of a philosophical brain-bender, but we’ll get to that a little later.

First, I want to say that top-down design really is necessary. You must be able to design say an automobile by starting with the overall idea of the automobile itself. The invention of the automobile evolved from the wheel up, but the design starts from the finished idea and branches down into individual details. Invention evolves and can be chaotic, but design is a very organized endeavor, and must proceed from the general to the  specific.

Your CAD system has to be able to handle this sort of design philosophy. The software has to have a way to allow you to start with a general idea, and make it more and more detailed. In the last post, though, it’s clear that many users have a hard time making the currently popular history-based modeler perform this task the way it is billed to fill it when working a design project from the top down.

We need to agree first that this is a real problem. My years as a CAD implementation consultant convinced me that at the very least, getting in-context methods to work correctly in a history-only modeler is tricky. You have to filter all of your ideas through the in-context filter before you go ahead and do it, because if you do something wrong, like use “undo” in an in-context place where it doesn’t work, or use configurations (family of parts/assemblies), or assembly features, or renaming, or even using a different instance (occurrence) of a particular part or subassembly, you could mess up the whole thing. And this kind of information can only be stored in the short term memories of the people doing the modeling work. There is no way to document this kind of knowledge. This is why people remove all of that intelligence at the end of the project. The next time someone gets around to working on this assembly, they aren’t going to remember all of the secret information that you need to know to make the design intent in this particular design work the way it was intended.

[pullquote]I realize it sounds stupid, but it’s true. The most popular CAD software relies 100% on the users memory for the effective use of in-context design[/pullquote]

So your design intent is only good for as long as you can remember it, unaided. Does that sound right? You pay thousands or tens of thousands for sophisticated CAD software, and you still have to rely on your memory??? Yeah, I realize it sounds stupid, but it’s true. The most popular CAD software, top-down design relies entirely on the users memory.

Realize as well, that not only does it rely on your memory, but it also only allows you to do things one way. Once you have set up the assembly to change in a specific way to changes, what happens when you need to make a change that doesn’t fit that method? Well, I’ve been there a lot. It’s painful. You have to make a decision. You either have to do a giant workaround to get the non-compliant change to work, or you change the way your assembly reacts to change, which is essentially like rewriting a program when you change what you want the program to do. Or you can nix the design automation altogether, and just make all changes manually. And doesn’t that sound fun?

But there’s another way of working. Imagine that software existed that would allow you to make changes in the assembly and would allow you to make up your mind at the time of the change what sorts of relationships you wanted to use. And then those relationships were immediately forgotten, and you could make another contradictory change involving different relationships without the need to break, delete, or ignore anything you did in the first change.

This software has been around for several years at this point, and it’s a name you know. For some reason, we’ve been keeping some of the more exciting functions of the software our own little secret: Synchronous Technology allows us to work with Synchronous Assemblies, which in turn brings some of the excitement of flexible design intent to in-context assemblies. It is far simpler than managing those “->” relationships and features, or those hidden links in the assembly document, or all of those inscrutable rules that you have to have an expert explain to you about feature order, and assembly features, and time-driven stuff versus things that aren’t time-driven in the assembly…. aaaarrrrggggghhhh!!!!!!!!!!!!!!!!

All of that brain-bending stuff just disappears with Synchronous Assemblies. Next time I’m here, I’ll bring a simple example to demonstrate.