Tuesday, January 15, 2013

Model-Based Engineering – Are We There Yet? (Part II)

  Part II    (Part I)

I've had many opportunities to conduct product development process assessments at some very large companies. In one such case I visited 4 or 5 different facilities scattered around the US. Interviews consisted of about 70 or 80 different people; VP's, Directors, Managers, and key contributors to the process. When I conduct these assessments I pay close attention to the input and output of each stage in the process. The output from one stage is of course the input to the next stage – in some form or another. Or, of course, that’s the way it should work. Then I like to look at the individual activities, methods and tools used to support that particular stage of the process, also noting where and how data is managed as it flows through the process stage.

During this particular assessment we identified over one hundred different software tools that were being used in the development and manufacture of their products. This includes authoring tools, analyzing tools, calculation tools, optimizing tools, documenting tools, managing tools, rendering tools, publication tools, presentation tools, communication tools, and so on. What is interesting to consider is that most of the tools that were actually used to create product specific data were creating a unique file type. And in many cases these files (documents) were not directly consumable by any of the other tools that may be on the “input” or “receiving” end of the data. Many of these documents were disconnected islands that required manual updating. My experience tells me that this situation is not too uncommon.

Of course multiple documents are a reality in any product development environment. A universal PLM/PDM environment will be critical in bringing these many documents together into one master. But there is also value in reducing the number of "documents". A tools consolidation initiative may be an important step towards "Model-Based". Considering the number of different tools used in the development of the product, how many disconnects could there be between actual product requirements and manufacturing. Disconnects always lead to standalone pieces of data, manual data entry and duplication of effort. Does your environment support "Model-Based"?

Here’s another interesting example. I've worked with many companies that can rarely ever generate a model based top level engineering BOM of their product. The BOMs are typically manually created. Keeping the manufacturing BOM up to date and accurate is likely tedious with much manual interaction. Unfortunately this situation is not too uncommon either. Are your BOM’s "Model-Based"?

There are many reasons that companies may not be able to generate a model based top level e-BOM. The assemblies could be so large that they simply can't load the entire assembly and scan it. But there can be other reasons. I see many examples of "overloaded" assemblies. Assemblies that are packed full of much information and detail that adds no value to the design, manufacture, or service of the actual product. Here is an example of what I mean by "overloaded".  Perhaps you are in the industrial equipment business. Your products are likely packed full of purchased components. In the interest of completeness and quality you request detailed 3D models from your suppliers and integrate them as-in into your design. If you are not careful in this integration process you can quickly and unnecessarily double and even triple the complexity and size of your assemblies.

Getting a model based top level e-BOM could be a fundamental step in making progress towards "Model-Based". As such, one of the first steps towards "Model-Based" could be to optimize the master through some best practices around data reduction and data integration. In the end, “Model-Based” demands a rich master. If the master is already too full and unnecessarily complex - you have a problem. Is your master optimized for "Model-Based"?

One last example. I've experienced a few companies where the end product is a highly stylized, ergonomic, creative, and attractive product. The product is more “touchy-feely” than highly engineered. In many of these cases the majority of all intellectual property is defined by the “Artist”, i.e. the Industrial Designer. It’s the job of the “Detail” Designer to make the product manufacture-able. In this situation, the design master is made up of the early concepts and aesthetic requirements. If a design change happens it almost always goes back to the artist. The change then ripples back through all the downstream stages. Can you guess how many times the detail designer might have to create and/or re-create the as-manufactured CAD model? Are your detailed 3D CAD models “Model-Based”?

I know I have some strange views on what “Model-Based” could be. Perhaps I'm completely off-base, but I hope I have stretched your thoughts on the topic just a bit. Let me know what you think. Feel free to add your comments below.

Paul

3 comments:

Jaseem Pratik said...

Binfer is a useful tool to send cad models without worrying about email attachment limits. Check http://www.binfer.com/promotions for info on getting free transfers.

Bill Ryan said...

A little food for thought...does it make sense to have multiple apps where each one can make changes to the cad object or does it make sense to have one app that is the single source of all changes and find a way to automate the rest of the use cases in the other apps(such as View). Seems like savings and efficiencies would be gained for the user generating the cad objects.

Paul Hamilton said...

Excellent question Bill. I guess if I was the one running things, I would want a single data object with purpose specific apps that can extract from, modify, and add to, the data object. One that would be used to support CAD, but also many of the other product development disciplines such as analysis, publications, manufacturing, and so on. This would require a very intelligent PDM system that would understand the more extensive data object. I personally would be more concerned with the number of data objects/files/documents than the number of apps - if there was a choice.