Planning Methods for Top Down Design

[JWayman]

It seems to me that Top-Down Design, using Pro/E or any other 3D CAD system, is very similar to Object-Oriented Programming. In both systems, commonly used data items are stored centrally and communicated to the program objects (sub-assemblies in our case) where they are used. Building blocks can be used repeatedly. Changes can be made in one place and 'rippled down' through the entire program (assembly).

In OOP, a Unified Modelling Language (UML) system is used to define the system at a high level. From this high-level model, a number of data items are extracted, the basic building blocks of the program are defined and the overall structure of the software system can be described, ready for the detailed code to be written. Requirements are used as inputs to the UML model and the model can later be used to assist in requirements proving. I know of no equivalent to UML in Mechanical Engineering design.

That is my simplistic, Mechanical Engineer's take on the process. I think it probably at least resembles the truth.

My question is to those of you who use Top-Down Design techniques: How do you plan your Top-Down Design system?

This high-level question rolls out into many supplementary questions:

Do you use a UML-based or similar software system to translate requirements into 3D CAD models? If so, what software do you use? If not, what do you use instead? If nothing, is there a gap in the market? Could/Should PTC be producing a software package to act as the bridge between Requirements Analysis software and 3D CAD? Does PTC already have such a software package? Is this an area in which certain 3D CAD packages do better than others? Etc.

I have done some Internet-based research and it is clear that I am not the first to see the link between software development and Mechanical Engineering development. For example. see this link: https://www.classle.net/print/24010

I am interested to hear your views on this subject, and the different ways in which companies approach it.

Regards,

John

This thread is inactive and closed by the PTC Community Management Team. If you would like to provide a reply and re-open this thread, please notify the moderator and reference the thread. You may also use "Start a topic" button to ask a new question. Please be sure to include what version of the PTC product you are using so another community member knowledgeable about your version may be able to assist.

[TomD.inPDX]

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 (?)

[BrianMartin]

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

[GregoryPERASSO]

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

[BillRyan]

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.