How to work on big CAD project in team?

Question

I'm always confused on what is the effective way to work on CAD with multiple team members to make it efficient. So far, as I'm freshly graduated I only work on a project where I'm the only one using the CAD software. At best there's only two of us, so we can work in one table and discuss directly to each other to be aligned on the part dimensions.

That is what I'm confused, how do team members align all the parts if they work with a lot of team member?

From what I know, on big projects there could be hundreds or even thousands of part, and I'm sure it is not only made by one person. But, if we make CAD in team, the problem that I come through in my experience is: I need to really align on how to assembly the component that they make to the component that I make. What makes it hard is it's really hard to be aligned on what's the boundary of each part, whether or not if the part is made in certain dimension it will hit other part. This is even harder when there is a mechanism, if it moves it will potentially hit other part as well

I'm also confused on how to divide the work in CAD projects. Say there is part A and B, which will be assembled together. If these part is done by different person, wouldn't it be a risk that it cannot be assembled properly? In this case its just two parts, what if there is like 50 or even 100 parts?

So basically, my question is, how is these works done in the industry? Especially for the big projects where there's lots of parts to be designed. I just can't figure out how to do this properly in team and hence I prefer to work alone.

Answer 1

It's a massively important question. Short response: apply the concept of encapsulation.

• Divide into subsystems
• During development, assign design-ownership (distinct from project manager role, although may coincide in a small group) to subsystems, and to the higher level design
• Define interfaces (mounting, electrical, thermal, plumbing, material flow, etc) for each subsystem
• Negotiate 3D working space for subsystems
• Make dummy models early on for designers of the other subsystems to use during development, showing the interfaces and claiming the 3D space reserved for each subsystem.
• From the very beginning leave more space to work in than you would need for a project where one person can have everything in their head. Likewise, expect it to take more time. Will need plenty of meetings to hash out the details.
• Beyond a team of 3-4, systematic project management, i.e. doing the above for requirements and project flow, as well as design itself, becomes very important too.
• Success here has as much to do with teamwork as design skill, although it's also very important that designers and engineers feel free to give negative feedback early on -- both to each other, and especially to whoever is organizing the system level integration of the design, and the PM. Without this, it's easy for bad design decisions to get "locked in" for the sake of making quick progress early on.

Answer 2

First, a big (100 or 1000 engineers) project is very unlikely to start from a blank piece of paper. A company like Boeing has designed many planes in the past, and therefore has a pretty good idea how to "guess" an initial design for a new one.

One method that works is to start from an initial "guessed" design and refine it. Given the requirements of the project, the high-level project management team agree on a basic design concept which splits the design into modules and sub-modules, and defines a "best guess" at the key dimensions of the interfaces between them, and the key functions that each module must deliver.

For example if you want to design a 250-seat passenger plane for long-haul flights, you can make some reasonable estimates of the size of the fuselage to contain the passengers, the likely mass of that fuselage, and therefore the lift force the wings need to produce, the engine thrust required, and therefore the size of the wings, how many engines are needed, the amount of fuel required for a 10,000-mile flight, etc, etc.

There may also be some arbitrary company-wide conventions which it is cheaper to follow than to deviate from. For example Boeing used to design all its aircraft fuselages in modular sections each 100 inches long. (Well, I guess that's as close to "metric" as you were going to get in the USA!)

Separate design teams can then work on each module (and divide it into sub-modules themselves if necessary) within the constraints of those fixed geometrical interfaces and functional requirements.

Assembling those designs into a complete "first design iteration" model usually won't work, because some of the constraints turn out to be impossible to meet. A high level review then revises the specification for each module based on what has been learned.

Typically there will be two or three such iterations before the overall design is "frozen" in the sense that the company is confident that the product can be built, how much it will cost to build and operate etc. There may then be more iterations on sub-models (and sub-sub-models) to refine the design further.

Note, the initial iterations may not be done by human designers at all, but by AI software which has "learned" from all the company's past history of successful (and unsuccessful!) designs. For example in the company I used to work for, we could create a high-level design for a new aircraft engine, as a variant of our current portfolio of products, in literally 2 days or less, with enough confidence to offer it for sale with guarantees of its performance and a known selling price that would be profitable - even though producing the final detailed design might take another 2 years before we started to manufacture the product.

---

Another aspect of this strategy used to be stated as "never design something you don't already know how to analyze". In fact that has developed into the concept that "technology acquisition" is a company-wide function in itself. Of course it is focused on the company's perception of what technology it will need in future, but it is not closely linked to individual projects in the sense of "This looks like a new cool design idea, now let's figure out how to do some experiments or simulations to see if it works or not". In other words, you already know how you can verify that the design will work, before you start the design process.

Answer 3

Your question is a fundamental problem and does not have a single way to be handled. IMHO it boils down to the management of engineers and designers and is fundamental to the success of a company.

IMHO (it might be very simplistic compared to what Jonathan R. Swift might have to offer, since I've only worked in a small company with less than 20 engineers and designers), it boils down to two vectors:

• Workflow for Engineering components design
• Software tools

Workflow/Procedural approaches

This is the back bone. This is how it was traditionally done, and its an arbitrary decision by the management of how they seem better fit to address the problems within the company.

So, it boils down to workflows like the following for an Engineering Change Request (Which I consider one of the fundamental blocks of the process).

Figure 1: Workflow for ECR (source SAP)

Basically the engineering Change Request workflow, describes the steps that need to be taken from the moment an request is made to change a part in an assembly to the actual manufacturing of the object and beyond.

IMHO, this is in the core of a successful engineering design team. This type of product management existed before software tools, and nowadays, the software tools (in the best of cases) adapt to a well thought of and designed workflow. If there are flaws in the process, then the software will only replicate these flaws.

Additionally, in order for the workflow to be successful in the implementation, it is important that users are trained to it.

Finally, one common problem with these workflows is that they tend to be too lax or too restrictive/pedantic. Finding the right balance is a complex matter and it even involves understanding and adapting to the core values of any team.

Engineering tools

Nowadays (for the past 30 or maybe 40 years) there are tools and even companies that specialize in setting up those systems. It can be from:

• a very generic enterprise resource planning (ERP) software like SAP which includes other aspects of the business.
• Software Tools from 3D CAD companies that help with the management (the problem is that they work mainly for their product usually). For example for solidworks there PDM and EPDM, for CATIA there is ENOVIA I think
• Additionally companies can seem fit to create their own products.
• Finally products like Onshape take the approach to the extreme in their basic product. Basically when you are developing a component, they are doing it similar to software product.

Figure 2: example of version and branching from Onshape

Other methods

Continuing on from the last note on Onshape, there are a lot of other things that can be borrowed from software engineering about product development methods (btw PeteW's answer which is great, revolves around the concept of encapsulation which is one of the tenets of OOP), in a modern design environment.

(Although some times nothing more than buzz-words) "SCRUM" and "Agile software development" and similar methodologies can offer useful insights, tools and ultimately solutions to the complex and dynamic environment of modern enterprises. The problem they set to achieve is improving the communication and the setting of aims of a group which are all working in the same problem.

So, IMHO, it boils down to improve communication between people and departments of the same company.

Answer 4

I would like to add a bit to the two answers above.

More of a practical explanation of your CAD question. Latest CAD, CAM and CAE software allow multi-user simultaneous work by using referenced models.

That is, as you mentioned the assembly with part A and part B. There's an assembly model that references (links) the models of the two parts. Also while working on part A the user could reference (link) the part B model and update it at any time to see how his/her model of part B fits.

In this example the assembly model could be used from the manager (or any other stakeholder) to check on the project.

These two (or a billion) parts could be stored as files or in a database, depending on the software used.

Answer 5

For your first question - how many people work independently but collectively to finish a product or a large project.

It is done by using cad collaboration software with a master plan that linking everybody's work and updates instantaneously, or at the scheduled intervals by the lead person. For the individual draftsperson, if linked properly, you are always working with the newest master plan in the background, and adding/revising your information at your own drawing board (page), then save it which will then be automatically uploaded to replace the outdated information. By sharing a common master plan, conflicts by different persons are noted immediately. All major cad programs already have this feature available through purchase.

Another way is to use BIM - the "Building Information Modelling" system, which is wildly used in the construction industry and by government agencies.

Your second question - how to divide the work, well, it really depends. But logically the division must be made at where a clear cut can be made without overlap between two individuals. Note each discipline may have its own divisions since the disciplines (structural, electrical, mechanical...) are usually working on different layers within the same environment and linked to the master plan. So while the individual designer from one discipline can view the detailed information of the other dicipline to make a measurement, and to avoid conflict, but he/she can't make changes to it.

Answer 6

I have no experience in the engineering industry, but I used to be part of an undergraduate engineering competition team that designed and built planetary rovers and autonomous underwater vehicles. Perhaps I can provide a perspective of doing CAD in a small team of 10 to 20 students.

• Members of the team usually have an idea of how the final product might look like. This might be based on their experience from building the previous iteration of a design, from building prototypes, from reading trade magazines, or from reading competitors' competition papers from previous years. Members meet, discuss, and make a rough sketch of the final product with rough dimensions. In addition, the first draft of a todo list is written. Using the rough sketch and the todo list, the team can start using CAD to produce the first iteration of the design.
• The project is divided into subteams of 2-5 people, with each subteam responsible for a different component. For example, there is a hull team responsible for hull design, a propulsion team responsible for the evaluation/acquisition/integration of propulsion systems, an electrical team responsible for power systems and sensors, etc. Each subteam maintains its own todo list. Each subteam eventually produces CAD designs of the parts that it is responsible for.
  • Normally, each part is input into CAD by only one or two people, after their subteam decides that it is able to do so. For example, when the electrical subteam has decided to use a particular off-the-shelf power system, the subteam will then create a CAD part of that power system, and modify any other parts that integrate with that power system.
  • Every part is placed into a version control system such Autodesk Vault. This ensures that two people are not modifying the same part at the same time. In addition, this allows the team to keep track of history and easily revert to a previous design if needed.
  • The use of parameters in parametric CAD allows dimensions to be changed easily when it is time to combine one part with another part.
• During weekly whole-team meetings, the project is discussed at a high level. This includes monitoring progress, modifying the todo list, discussions about integration between parts (i.e. the fixing of dimensions between parts), etc.
• Not all subteams will complete their designs at the same time, but after many iterations of the above, the parts will start to approach a point where they can be seamlessly fitted into an assembly.