Planning Methods for Top Down Design

Not to much to say about this other than the fact that I never thought of it in a "programming language" way.

I think of it as an "idea generator" only in the fact that I -can- tie feature dependencies together across assemblies.

In general, most of the companies I've worked for frown on this type of structure in released designs. In that sense, I have been "conditioned" not to do use top-down development techniques.

But now that you mention it, I can understand how Creo is doing this in the background. I have a programming background, but I really never gave it much thought from an engineering perspective.

I wonder if the Skeleton models were a beginning of this thought (?)

Hi John...

Interesting analogy tying UML to Creo.This is the kind of thing you could talk about for hours. I completely "get" your comparison. I'm doing some OOP/UML right now actually so your observations made a good bit of sense.

But moving on to your general question... how do companies capture their requirements and allow them to flow down into the design?

Answer: Most of the time this is done manually. Some person is responsible for communicating a list of requirements to the mechanical engineer (or mechanical engineering team) who then sets about creating the design.Often requirements are poorly captured, miscommunicated, or missed altogether leading to numerous revisions, changes, and last-minute modifications. It's a very imperfect process.

PTC does actually make software already to address the problem... it's called Windchill ProjectLink. With ProjectLink you can capture requirements, tie them to the overall product you're developing, and assign roles/responsibilities to team members. ProjectLink helps manage a project... down to individual components if that's what you wish. The system only works as well as it's being used... so it's possible to use ProjectLink and not capture requirements, too.

Ideally, a team could identify the need for a product, capture design drivers, requirements, restrictions, etc. These can be communicated to all stakeholders through the system. High-level planning for the final product can occur before any 3D modeling has been done. You can fully define and redefine the product structure, assign part numbers, and assign design responsibility to various team members. As the design matures, ProjectLink can provide metrics on project health- Are you hitting your deadlines? Are you satisfying requirements? Do you need more resources to meet your goals? Etc.

There are certainly other pieces of software out there to capture requirements and perform system-level engineering. One such piece of software would be Doors. There are others, too.

Anyway... hope that starts to provide a credible answer to your question.

Thanks!

-Brian

Hi John,

In my previous company (A&D, world leader in gas turbine for helicopters), we do work with a top-down approach

And not only of a strict CAD point of view , but in the PLM Point of view

All requirements (from marketing, clients, etc ...) were captured in Windchill as strucured "function" objects (we develop our own Requirement Link before PTC 😉 ) . we can links Specification documents, etc ...

Each of these functions are translated (and linked) with a structured "Organic" objects. (a kind of "functional modules" Bill of material) They were structured regarding A&D normalization (ATA). On this strucuture is linked CAD datas (skeletons, modules interfaces, pre studies ...)

We

And then each Organs is fully detailed (concretized : link between organ and WTPart): detail design of CAD part and assembly respecting skeletons and interface. related WTpart BOM ...

like with Requirement link, you're able to analyse impacts from requirements to "real" product definition.

And other product information ...

we also use the central organic BOM to link Service (MRO Maintenance Repair and Overhaul) informations. cause even if specifications change, and then a change is propagated in the "real" WTPart BOM/CAD structure (lets say a replace of a part), we need to track this and display it in maintenance guide (Service management with Arbortext integration before PTC bought it 😉 )

But more than a good PLM implementation, the Company was organized to work like that.

For example, in the engineering department, there is a special team in charge of defining all CAD interface and skeletons, managing interferences ...

regards

Gregory

Our company is in the automotive industry and every vehicle coming off the line has a different combination of 19000 options. Changes are being made all the time within small programs and there are large programs included in the equation too. We use a combination of top-down and bottom-up approach for the develpment groups. A top level assembly is generated for each model and engine combination and then system assemblies are added to each one. We use a coordinate system methodology to position each sub-system. The system assembly should have a home base coordinate system. IE...an engine component will always constrain to a defined common physical location on the engine like the center axis of the crank and front face of the block. Scope Documents, BOM grouping, build area, position on vehicle are all considered when creating the system assemblies. Systems that span multiple areas of the vehicle like routing and HVAC provide challenges. There has to be a lot of thought in naming the assemblies to enable users to navigate the tree structure. consistancy is key. The higher up in the model tree, the more generic the name should be. Never ever use family tables for system assemblies...if a family table is used, it must be the leaf of the tree....never a branch or a trunk! Use simplified reps to manage variation...or investigate the ANYBOM method. I have a lot of users complain about the multiple levels of assemblies, but the ability to collaborate by giving each designer or group an assembly to work in is important for us as only one person can be modifying an assemlby at any given time. We also use the feature name column to help define conditions of use and add descriptions to improve navigation and aid in managing the simplfied reps. As an example, we can assemble a fuel tank at every inch on the chassis...so we need a method to help describe a 150% overpopulated assembly that has the tank assembled multiple times. Do not use groups in the model tree to organize systems because Pro-E treats these as features and the filters will always show in the tree structure which impedes navigation when the user wants the model tree to only show what is active on the screen....create sub-assemblies for this case. And also Creo View does not support Groups at this time. It is imperative that users understand how to seperate reference information to keep non-system related objects out of the applicable assemblies. IE...you don't want to see a frame rail when you're in a fuel tank assembly. Our best practice for this is to have each user create a personal assembly and then have the top level vehicle assembly included as the first level assembly. This gives them access to all the reference information to design their widget and be up to date as any system assembly changes. It is frowned upon to have engineers search for and try to create their own single level assembly. The end goal is to minimize the number of system 150% overpopulated assemblies. As an example, if we were GM/Chevy. We'd have a generic assemlby called "seats.asm" that could be populated in the top level Camaro or GMC truck assembly. Under the seat assembly is a coordinate system common to the mounting of the floor...then there are seats assembled for each option of the Camaro or GMC. The advantage here is that one assembly is being managed to contain all seats along with enabling designers to easily see a space claim of all seats if so desired. And one last note, if you do have confidential information within the system, like two seat suppliers, then a sub-system assemlby has to be generated and that sub-assemlby must reside in the controlled folder so your on-site supplier can not see the competitors file when working in the assembly.