ENOVIA Data Management: Less PDM-ish, More PLM-ish

References Cited

Dassault Systèmes, What is MCAD?, Product Lifecycle Management (PLM), What is Product Data Management (PDM)?

All CAD data management is the same, right?

You create a 3D model. You save the file. You check it in. You move on.

That might have been the story for the last 15 years, but now, it is changing in many ways. At the beginning of 2013, I wrote about how The PDM Revolution is Upon Us, Brought to You By CAD in the Cloud. My points there still hold true. However, after a briefing with the folks at Dassault Systèmes, I’ve realized  there’s a lot more changing with PDM than I thought.

This post provides details on ENOVIA data management capabilities as well as my perspective on how it can impact an engineering organization’s ability to collaborate.

ENOVIA Data Management Capabilities

How does ENOVIA manage design data? To really answer that question, we need a little context.

CAD and the Evolution of PDM

When 3D modeling first emerged, there was a figurative explosion of CAD files. Each individual component had a file. Each assembly had a file. Each drawing had a file. Additionally, many of these files were interconnected. A change to a part updated the assembly associatively. Very quickly, engineering organizations realized they needed PDM to manage it. And interestingly, PDM systems initially were developed to solve this problem.

That, however, wasn’t the only problem. CAD models have never been simple files. Lots of stuff have been, and continue to be, jammed into them. They contain far more than just geometry. They contain part numbers, so drawing BOMs  populate automatically. They contain material properties, such that mass properties can be calculated. Over time, as more and more enterprise considerations needed to be taken into account, more non-geometry stuff has been jammed into CAD files.

The problem with all this stuff in CAD files was that, unlike many other types of files, operating systems couldn’t understand the structure of information in CAD files. Windows couldn’t pluck out a part number out of a part file and present it to a user. Instead, that file had to be opened by the user so they could see it. Ultimately, this was another problem that PDM solved, but that was secondary.

What is ENOVIA Doing Differently?

How is that context related to ENOVIA’s data management capabilities? Well, the folks at Dassault Systèmes are trying to liberate all that stuff jammed into the CAD file. Here are some notes from my briefing with them.

In short, they are taking non-geometric items in CAD files an turning them into meta-data that lives in ENOVIA. They are being turned into individual pieces of information that can be modified separately and independently from every other piece of information and the geometry. Of course, this meta-data is related and will live as a database item right alongside the file that contains the geometry.

OK. Got it? Now, let’s discuss the important question: why is this important?

So this is the critical capability. I know. It might seem like a very nuanced thing. But there are some big implications. That is coming up next.

Commentary and Analysis

Let’s start with the most important part, which is…

Simultaneous Modifications

To show why this is import and different, let’s walk through an example.

Let’s say that we have two users that need to edit a part. One wants to change the part number. The other wants to change the material. To date, the way this would be accomplished would be as follows. User 1 would check out the CAD file. They would modify the part number. They would check it back in. User 2 would then check out that CAD file. They would switch the material. They would check it back in.

The important point here is that those changes occurred serially, one after the other. With two users, that may not be a big deal. But once you scale that up to, say, twenty users collaborating on 100 parts, users need to get in line to modify a part. Or worse yet, users simply own a part with no one else touching them, eliminating any collaboration.

With Dassault Systèmes’ approach, the need to explicitly coordinate change or wait in line for modifications is removed. All that meta-data can be modified simultaneously and independently. Design teams can work more collaboratively and quickly.

Design Information Management

Now, given the context of what we just went over, it feels like this is a pretty fundamental change. To date, PDM breaks down into three areas. There is CAD data management, which is essentially very specialized file management. There is engineering data management, which is getting all your other specifications, calculations spreadsheets and whatnot alongside your CAD files. There is enterprise data management, which is getting all the deliverables created by the rest of the company alongside the engineering artifacts. Put all together, these three areas make up a fairly complete product record. My point here is that the unifying trait of all three of those PDM areas is managing files.

PLM, on the other hand, doesn’t really manage files. It manages traits and characteristics of processes and products, and there certainly is a lot of that, as meta-data in a database.

And that’s is what strikes me as interesting. PDM has basically always been about managing files. PLM has basically always been about managing meta-data. But here I am talking about managing what used to live in CAD files, and therefore used to be PDM, that is now living in a database, which used to be PLM.

Terminology is always difficult in this industry. But in my mind, I can’t used the traditional file-based PDM term to describe it. This is more like Design Information Management, with a little geometry added in.

Scope

In this post so far, I’ve continually referenced the CAD file as the thing being transformed into meta-data. But what we’re talking about here isn’t just limited to CAD , it’s a movement that extends to simulation, manufacturing models and much more.

I haven’t verified this explicitly with Dassault Systèmes. However, I fully expect that loads and boundary conditions, mesh constraints, material properties and much more from simulation models will be teased apart and managed as separate items in ENOVIA. Similarly, I expect tool speeds and feeds, tool selections and NC sequence and operations will likewise be plucked out of the manufacturing model file and managed as individual things in ENOVIA. Basically, anything that isn’t geometry will be going in this direction

The rationale, by the way, holds true in each of these cases. Simultaneous modification of these entities to enable collaboration.

The Objections

In the modern era of this industry, I haven’t really seen any other CAD-PDM interaction like this. Obviously, for Dassault Systèmes, that provides differentiation. However, because it is so different, it also poses some interesting questions with respect to interoperability.

Let’s say, for example, someone wanted to take a CATIA model and push it over into a different CAD application. It will be relatively straightforward to get the geometry out of ENOVIA. After all, that’s just a file. But the key question is this: what else should come with it? I expect that ENOVIA can and would be able to dump in all sorts of meta-data into a file, but what parameters should go with it?

By the way, this issue exists in some form or shape between other CAD applications today anyway. The parameters that are tracked and managed in a CAD file for Creo are likely very different from that used in Inventor Fusion as well as NX. There’s some parameters tracked in one format that isn’t tracked in others and vice-versa. When it comes down to it, this kind of problem already exists.

Summary and Questions

Yes. Yes. I know that was a lot. But it’s a complex issue with nuances that matter. Now, let’s recap.

  • To date, CAD files have been full of meta-data that is not geometry based. A modification to any meta-data item or geometry forces a uprev in the iteration of that CAD file. This can limit the ability of a team to collaboratively design because it forces users to sequentially change that file via PDM.
  • Dassault Systèmes is plucking practically all non-geometric meta-data parameters out of CAD, as well as other, files so that they become database entries. This allows them to be modified separately an independently from one another. This also enables users to modify them simultaneously instead of serially.
  • This marks a change for PDM, which has traditionally focused on a specialized version of file management, to now become more PLM-ish in that the focus is more on database management of meta-data.
  • I expect the scope of this database management of non-geometric items to not just be limited to CAD, but extend into simulation, manufacturing and beyond.
  • Because this stands as a different approach to managing design (and other) data, it raises questions with respect to interoperability. What meta-data should be exchanged? However, this problem exists today, in some form, between the most frequently used CAD application formats. There is no 100% match in what is tracked and managed within those CAD files currently.

Penny for your thoughts? I expect there will be some good discussions on this one. I’m looking forward to it. Leave your thoughts!

Take care. Talk soon. Thanks for reading.

Chad Jackson is an Industry Analyst at Lifecycle Insights and publisher of the engineering-matters blog. With more than 15 years of industry experience, Chad covers career, managerial and technology topics in engineering. For more details, visit his profile.