As I’ve said before and I’m sure I’ll say again, terminology in this industry can be a source of confusion. And even though it’s been around for quite some time, PDM can actually fall into that same category. If nothing to add a little more clarity to how PDM is defined in the posts on this blog, I wanted to give my perspective on what falls inside and outside its scope. And my opinion is that PDM is much like an onion with many layers to it.

Inside Engineering

Let’s start within engineering. Specifically, let’s look at how PDM manages artifacts that represent a product’s form and fit.

Managing Design Representations

A few months ago, I wrote a series of blog posts on how different aspects of mechatronic products are managed. Won’t reinvent the wheel, but I’ll pick out the most relevant stuff here.

  • Managing Mechanical Designs (Mechatronics Management (Part 1): Managing Mechanical Aspects): This type of system manages all the different types of deliverables that Mechanical CAD produces such as 3D models, drawings, assemblies and the like. These systems also extract detailed information from these deliverables for enterprise access as well as manage the interrelationships between the deliverables, of which there are many.
  • Managing Electrical Designs (Mechatronics Management (Part 2): Managing Electrical Aspects): This type of system parallels the capabilities provided by MCAD oriented PDM systems in that they manage the diagrams, schematics and drawings associated with PCBs as well as the electronic parts libraries that are used to assemble the boards.
  • Managing Software Artifacts (Mechatronics Management (Part 3): Managing Software Aspects): The similarities in the prior two systems continue in this type of system, often called Software Configuration Management (SCM) in that the various code snippets that make up embedded software are configuration managed and tracked.

When I run into someone and start talking about PDM, it’s often the very first one we hit on here: PDM for Mechanical CAD. It was one of the earliest types of systems to become widely used in engineering. But as you can see from the other types of systems that are available, there’s a lot more to PDM than just managing Mechanical CAD. But so far, we’ve just talked about managing design representations. Let’s continue.

Managing Simulations

Another aspect that engineering organizations are starting to centrally manage are simulation artifacts. Just last month, I published a post titled The Misnomer of Simulation Lifecycle Management, Here’s the most relevant excerpt.

SDM manages and controls the artifacts that are used to execute simulations as well as the results of those simulations. There are terrible complexities that need to be managed there as there are interconnections between simulation artifacts and MCAD design models as I have published in a post titled The Pitfalls of Multi-Disciplinary Simulations: Divergent Model Abstractions. Furthermore, there is also complexity in terms of managing the ‘who does what’ scenarios amongst a team of simulation analysts or engineers and designers executing a simulation driven design initiative per a post I published titled Is Teamwork the Key to Simulation Driven Design? This stuff is no joke. In many ways, managing the simulation model, all of the simulation cases and the results in addition to their connections to abstracted as well as original MCAD models is far more difficult than simply managing MCAD models through their progression towards design release.

Most of the types of simulations that are managed so far are very oriented towards mechanical engineering. And there are certainly many simulations relevant to electrical engineering that don’t seem to be supported today.

Furthermore, anyone that develops embedded code often test the codes for ‘bugs’ against a battery of simulated tests to track quality. There is a strong need to capture as well as track which software configurations performed well and poorly in that context. Furthermore, each test can progress and mature over time, which of course needs to be tracked and managed as well. Some SCM systems provide this capability.

Managing Engineering Documents

Despite the overwhelming buzz in the industry about CAD and Simulation, engineering organizations need to track and manage a huge amount of documents, spreadsheets and presentations. They might be engineering specifications. They might be Failure Modes and Effects Analysis (FMEA) documents. They could be forms that are used in processes.

Some call this document management as opposed to data management, however, these are often not standalone documents. In many cases, these documents need to refer to information that is extracted or comes from different design representations such as a Mechanical CAD model or an Electrical PCB schematic or even a Multi-Physics Simulation. But that information shouldn’t be static, it needs to dynamically change as the information in those artifacts change. Some systems provide some ‘dynamic linking’ such as this, but not many.

Outside Engineering, In the Enterprise

Now of course, Product Data Management (PDM) isn’t just about managing stuff within the engineering organization It’s about the enterprise too. However, there are two progressive ways in which it can be used.

The first is all about access. A prevailing concept is that many other stakeholders in the enterprise would greatly benefit by having access to the information generated within engineering. If they could, they would make better decisions in their domains. Procurement agents could source functionally equivalent but cheaper parts. Service planners could start designing their procedures earlier. Marketing managers could start generating their collateral far earlier as well.

But that’s not the whole story. There is also the concept of Enterprise PDM. The basic idea here is that every organization in the company uses the same PDM system to manage all of their artifacts and deliverables, creating some type of interdependency or linkage between related documents. When one changes, the owner of dependent documents get a notification to update it. Of course, that leads to a discussion about how feasible Enterprise PDM truly is, but that’s a topic for another post.

Summary and Questions

Let’s recap.

  • The term Product Data Management (PDM) can have a variety of different definitions.
  • One aspect of PDM is the management of design models and deliverables that are discipline specific. These different aspects can be called PDM for Mechanical CAD, PDM for Electrical CAD and Software Configuration Management (SCM).
  • Another aspect of PDM is the management of simulation artifacts and deliverables. This is often called Simulation Data Management (SDM).
  • Not to be forgotten, engineering organizations author a wide variety of documents, spreadsheets and presentations that should also be centrally managed. This is sometimes referred to as Engineering Document Management.
  • While there is value to enabling other enterprise stakeholders to access engineering information, there is also value in managing all deliverables across the enterprise in a centralized system as well. Such a concept is often coined as Enterprise PDM.

That covers the range of PDM definitions that I can recount. Where there any other aspects that were missed? But additionally, where do you see most PDM implementations occurring today? WIthin engineering and only for Mechanical CAD? How many have seen an Enterprise PDM deployment? I’m curious to get your perspective. So weigh in!

Take care. Talk soon. And thanks for reading.