On PLM (In)Compatibility

By April 4, 2014March 15th, 2020Automotive, PLM

Long-term Product Data Retention

I have been doing some work lately around issues of long-term product data retention: how long companies retain product data, the laws and policies – existing and upcoming – that regulate these practices, and whether the frequent releases of CAD and PLM software impact the ability of product data owners, and potentially regulators, to access legacy data.

One question, of course, is the backward compatibility of PLM, PDM and CAD software tools. Some of the comments on company websites and blogs are surprising and even entertaining (unless, of course, it’s your data that does not load after a major upgrade.) Here are some verbatim examples, with software tools and vendor names removed.

  • I understand your frustration, but [CAD Tool] is not built in a way that would make backwards compatibility practical.” CAD expert.
  • [PLM Vendor] supports use of software 3 versions back… I do understand the request to support backward compatibility of files but this is not something that has been supported in the history of [CAD Tool].” Sr. Subject Matter Expert at [CAD Software Vendor].
  • I just want to make sure I have this right. I spent a bunch of money upgrading to 2012 and now I can’t share drawings with my consultants, many of whom use older versions of [CAD Software]?” CAD user.
  • Anyone who has ever attempted to move from one version of an enterprise software application to the “new improved” version knows that upgrades can be painful and costly. The critical elements of any enterprise software upgrade are data compatibility, ease of deployment, and compelling business benefits from the upgrade. Data compatibility is something that cannot be an afterthought. It has to be designed into the new version of the software. Ease of deployment of complex enterprise software requires robust and flexible state-of the-art architecture. It requires hardware and networking considerations. It requires that the software solution has captured the customer business process it is trying to transform. And above all it demands a unique long term partnership with the software vendor.” From a PLM vendor’s blog.

You may recall the wave of PLM system changeovers made by major automakers back in 2010-2011, as reported by Automotive IT:

Upheaval in the PLM market: Daimler and Chrysler are separating from former partner Dassault Systemes and are doing development work with Siemens PLM software. On the other hand, BMW has settled on Dassault in the E/E domain. In turn, Hyundai has chosen PTC’s Windchill as its collaboration software, making it the backbone of its PLM strategy. The PLM market is on the move in a big way.

While such dramatic changes are less likely to happen again, there is a lingering pain of periodically upgrading PLM and CAD software, and exchanging CAD models across the fragmented design collaboration chain. Users feel new releases happen too frequently, and often they are not sure about the value the new software provides. They want to know how long, how disruptive, how much will it cost, what’s the value? From an ongoing survey I am running, it appears that companies often skip a version or two (sometimes more) before they endeavor an upgrade.

And then, not all companies bother to upgrade data of older products and all prior versions of current product. The effort does not seem worthwhile.

The potential risk in not upgrading all data during every single upgrade is, of course, that sooner or later some CAD models won’t load into the PLM system. And it’s not necessarily the fault of the PLM software itself. As I am getting deeper into the intricacies of CAD data structure and interdependencies, and the workflow and data management practices of design and engineering organizations, I am discovering how easy it is to create data errors and structural inconsistencies that don’t manifest themselves for a while, until one day the model you just checked out will not check in, or the newly released PLM software refuses to load a model that you thought was perfectly fine. Discussing these issues in detail is outside the scope of this blog entry, but you can get an appreciation for the types of problems often found in CAD models in the highlights of data analysis conducted during a project to consolidate four PDM systems:

  • Approximately 20,000 missing dependencies. Data owners were able to recover only locate about 75%. The rest had to be recreated manually.
  • Approximately 25,000 duplicates. File/model names had to be rationalized and renamed manually.
  • Approximately 1,000 missing files. Unrecoverable.

A Question of Compliance?

One critical aspect of maintaining access to historical product data and, therefore, software backward compatibility, is the need to comply with relevant guidelines and regulations. The survey I am conducting shows that while some companies are aware of these requirements and, in fact, expect more to come in the future, other companies are unsure if and how they are subject to data retention and access guidelines. Below are a few a few examples of regulatory guidelines to consider. While the relevance and impact in your business may vary, these guidelines evolve quickly and it’s safe to assume that requirement to track product data throughout its lifecycle as long as the product is in use will only continue to expand.

EU Directive 2011/65/EU

RoHS Manufacturers or their “authorized representative” must submit technical documentation (to substantiate compliance) upon request of a member state enforcement agency, and retain such documentation for 10 years after a covered product is placed on the market.

FAA AC 20-179

Data retained by you must be made available to the FAA when requested. The FAA may use the project data retained by you for any official purposes such as production inspections, technical oversight of designees, design reviews, continued operational safety oversight, or any other reasons deemed necessary by the FAA.

You are also responsible for providing the FAA with all data in a format that is readable by the FAA. In the case of legacy data, you must be able to retrieve the data (or transfer it to other media that will be retrievable). When the data is transferred to another media, you must ensure the FAA has the means to access all previously submitted data as well as new data submitted to the FAA.

H3 DoD 5015.2

RMAs [Record Management Application] shall provide the capability to access information from their superseded repositories and databases. This capability shall support at least 1 previously verified version of backward compatibility.

Ongoing Research

Product companies should realize they need a product data retention strategy that ensures perpetual access, software compatibility and compliance not only while the product is in volume production, but  possibly as long as it is being used. This strategy requires an alignment with your PLM/PDM and CAD software vendors release planning in order to prepare for data migration and verification if needed. And while you are at it, it might be beneficial to revisit your CAD data management workflow to reduce the occurrences and severity of data errors.

Further reading