CAD Data and PLM

CAD Data and PLM

The following blog article drove my attention yesterday: CAD File Management ≠ PLM. The short blog post published by Peter Schroer of Aras. The summary of this post, in my interpretation, is simple. CAD Files and design represent a small portion of business problems in a manufacturing company. So, when you are going to make your PLM decision, think about a full scope of business problems – not only about CAD data. I specially liked the following passage from Peter’s post:

I’m not saying don’t let the CAD guys use what they want.  Let them use their system of choice for CAD file management.  That’s no problem – today’s enterprise PLM systems can move data in and out of it easily. But you’ve got bigger business issues than CAD file management, like LEAN, configuration management, workflow processes, quality, compliance, supply chain integration, FMEA, etc.

Peter is referencing deelip stating the following – “CAD geometry is 1/20 of what it takes to produce and maintain a part” and making straight conclusion “If CAD only accounts for 1/20 of your product, don’t let it drive 100% of your decisions.”

In my view, the discussion raised by Peter raises a very interesting question. How much attention PLM should allocate to CAD-related problems? How it is important for PLM to be deeply connected to CAD systems and CAD data?

CAD Roots and PLM

PLM, as a software, was born as a natural extension of CAD businesses. It initially started as data management for design and engineering, it grew as an important function to manage product development processes. Connection to CAD (design) data provided an important information to drive product lifecycle in an organization. However, this deep connection, also made a bad service for PLM. On a system level, it created an additional level of complexity and increase product dependencies. On a business level it, some of vendors started to use CAD-PDM/PLM dependencies in order to realize their competitive advantage strategies.

CAD-Rootless PLM?

Is it possible to create a PDM/PLM software disconnected from CAD and design roots? Companies were looking for answers on this question for the last two decade. Many of these companies went out of business or were acquired by CAD or ERP vendors. The idea of focus on product development processes without having deep roots in CAD, seems attractive to people these days too. I can see a kind of renaissance of these ideas influenced by modern technologies (the Internet, SOA, etc.).

Importance of CAD / PLM integrations

However, I can see a problem in a significant disconnection between design and rest of product development processes. The last release of Oracle Agile PLM 9.3.1 announced on Oracle Open World last week, stated the importance of multi-CAD integrations. It represents a clear path for PLM product to stay connected with CAD.  In addition, the last paper from CIMData – Ten Questions to Ask PLM solution supplier presented the importance of PLM system ability to stay integrated with multi-CAD and ECAD data.

What is my conclusion? PLM is focusing on solving manufacturing business problems. The key manufacturing problems are related to how to control a product cost and optimize business. When 70% of a product cost defined during the design stage, the reliance on the design data becomes more than important. This is a strong point behind CAD driven PLM decisions. However, if your system becomes locked in the engineering department, you are barely able to drive a complete view on how to control a product cost and optimize business. The connection between design/engineering and rest of the business is the most challenging piece of a successful PLM implementation.

Best, Oleg

Share

Share This Post

  • Stephen Porter

    Oleg,
    Well said as ususal. This is a pet topic of mine and I have published several articles on this topic including-http://www.zerowait-state.com/blog-plm-perspective-stuck-between-a-rock-and-a-hard-place-the-plm-dilemma-with-engineering-data and Peter touched on some things we have learned firsthand. For example if you look at Agile PLM’s customer base a low percentage of those clients use AgilePLm to manage CAD data yet their PLM solution functions quite effectively. If you look at PDMlink or TeamCenter I would suspect almost all of these companies manage CAD data as part of their PLM. I think it is dangerous to generalize about product design. The 1/20th number Peter sites might be true across the board but depending upon the product I suspect CAD plays a more prominent role is some companies versus others and I think this drives the decision on which PLM to use. I also agree that you need to look at the big picture and make sure the PLM solution you choose allows the entire enterprise to perform effectively but you may have to compromise.

  • beyondplm

    Stephen, thank you for commenting! I remember the post you mentioned. I think, there are different aspects of connection to CAD systems. I’d try to differentiate between connection to design information (in various ways) and connection to CAD/design systems. I think the first is absolutely important. The connection to CAD system is something that used a lot of companies/vendors to create additional software dependencies. I can understand a certain business perspective behind this, but not actual product/functional need. Just my opinion. Best, Oleg

  • Stephen Porter

    You are absolutely right. I am not sure there is a legitimate business case for having CAD data stored in your PLM. I think it can add unecessary complexity and also affect performance. Obviously you want the product structure and attribute information but the value of the physical models is questionable. The counter to this arguement is having the physical models vaulted in the PLM gives you a single source of truth and the ability to use the PLM to share the CAD data to external sources and to collaborate more effectively but I think this can be accomplished with viewables and zip files just as easily.

  • beyondplm

    I’d be arguing if “a single point of truth” can be achieved by connecting CAD data into PLM. Nevertheless, it is really needed, in my view, to be able to have “design data” connected with the rest of the product and business data. The technology may vary… Best, Oleg

  • H J Pels

    How to avoid CAD/PLM integration.
    Because designers/engineers do not understand the need for PLM and because PLM systems are mainly developed and sold by CAD vendors, there is a tendency to hide the PLM system for the designer behind his CAD system. This causes a strong integration between the two that appears to be very expensive in maintenance. Therefore my advice to PLM users is: use as little from the interface as your process really needs.
    My principle is that the PLM system should be leading over the CAD system (and the ERP system). The reason is that the idea of a product originates before the engineering order can be given to the designer, so the product item should be in the PLM system even before the CAD system knows about it. Of course you need the CAD system to edit the geometry of mono-parts, but to define an assembly, you only have to define the relative positions of the parts. Again a CAD system is the proper tool for that, but preferably first define the parts list in the PLM system. Of course you use the PLM system to view the 3D picture of the assembly, but the you view the JT format and not native CAD, so is does not matter from what CAD system the parts come ore in what CAD system they have been positioned.
    The problem is that in the PLM/CAD integrations I know, the CAD system is not even able to accept an design order, or an assembly task from the PLM system. Their developers have not even understood the proper process. They integrate what should be left independent and they don’t integrate what you really need.
    Henk Jan Pels, h.j.pels@tue.nl.

  • pfnelson

    I see a strong business case for having CAD data stored in your PLM system if your PLM system is managing requirements. To have all the relevant requirements available and enforced against a developing design ensures the designer remains within the constraints of his design space.

    Oleg, I would be interested to hear your thoughts on a systems engineering based approach to PLM that focuses on end to end requirements traceability throughout the PLM system from cradle to grave.

  • beyondplm

    Henk Jan, thanks for your comments and insight! What is in your view the root cause of poor PLM-CAD integration? You mention “designer/engineers don’t understand the need of PLM”. Where is it comes from? In my view, this should be a starting point for the discovery of problems. The question of where objects need to be first is very depends on the type of process. For some cases, I can see data management (that’s what I believe you call PLM) need to be a starting point. However, if this is a design task, CAD needs to popup first. What is your view? Best, Oleg

  • Jim Hamstra

    Henk,

    You are absolutely correct. Especially for MCAD systems there is a default assumption that parts originate within the CAD system. And you have a mess even if you try to generate the part numbers from outside the CAD system if you are using said CAD system to design them.

    ECAD systems solve this problem by separating structural design (schematic level) from physical design (PCBA or IC layout). It is possible to incorporate a part into the structural design for which no physical embodiment yet exists. The physical embodiment only needs to be present to complete the physical design.

    I find that ECAD users are more inclined to proceed top-down because their tools encourage this kind of flow – whereas MCAD users are more inclined to proceed bottom-up because their tools encourage that kind of flow. Or are the tools merely reflecting the traditional working mode of their users? Which is what “intuitive” actually means.

    For the same reasons the ECAD users tend to be more comfortable with the idea of leading with PLM vs the MCAD users.

    Jim

  • beyondplm

    pfnelson, I like your comment. I think, managing traceability between design and requirement can be very beneficial. However, only very big companies can afford such solutions, in my view. For the rest of companies, it is too complex to go with a single PLM approach. What seems to me more beneficial is to be able to connect data between different systems (i.e. Requirement data and design data). What do you think about such approach? Best, Oleg
    PS. I will put PLM and System Engineering post in my queue and hope to address it in the future.

  • beyondplm

    Jim, Agree with you. From my practice, ECAD users can be easier tolerate top-down designs. In MCAD, top-down mostly works when a very complex configuration comes to play (i.e. auto- / aero- etc.). Best, Oleg

Subscription Options:

Subscribe via RSS

Popular Posts

Recent Posts

Archives

Blogroll