PDM, its troubles and alternatives

Art is in the eye of the beholder. I consider Computer Aided Modeling (CAD) to almost be an art form. It is one of the few ways other than VR to truly experience an entire physics based environment without actually manufacturing anything. But the tools we use for it have become one of the major pain points for the engineers working on them. In fact, one of the first advice any senior CAD engineer is going to give you is to save often. CAD softwares can rival if not surpass the unreliability of Adobe Suite sometimes. But modeling is a very calming and therapeutic activity (to me atleast). There is a sense of creativity and ingenuity to it. The frustrations of CAD often rise from the factors that fundamentally separate it from an art form. It is technical documentation. It originated as a way to communicate the design intent between engineers.

Introduction:

Product Data Management (PDM) systems are essential to organizations that deal with large database of technical product information. PDM systems are used in versioning of designs, communication and transfer of files between engineers for design reviews, creating ECR, ECO and ECNs and are necessary for continuous iterative improvement.
Product Lifeycle Management (PLM) systems are fundamentally business and financial operations related softwares that help in collaboration between users across the organization to manage the Technical Product Information.

A well-defined PDLM environment should:

  1. Host the library used for CAD design.
  2. Provide a distinguished security and access model for the libraries that restricts all changes to a designated set of librarians.
  3. Provide efficient mechanisms for managing large families of similar items.
  4. Prevent or reduce the occurrence of duplicate or multiple part numbers and designations for an identical physical device. A part number should map to a specific, unique set of specifications.
  5. Address the maintenance of additional metadata for standard parts such as standard identifiers, extensions for tracking the configuration of mission sets, and effectivities which map revision/versions to the extensions.
  6. Manage the parts data developed by the design organizations developing the product.
  7. Allow for inclusion of new libraries and mechanisms as new organizations enter the environment, new suppliers are added, and parts suppliers are consolidated or removed from the marketplace.
  8. Provide for library availability for the required life cycle of the program/project.
  9. Host the library used for requirements development and requirement-to-part associations

Personal Problem:

I’m a mechanical engineer who does CAD all day. I work with assemblies and part drawings which are sent to manufacturing on the other side of the planet. I live in SolidWorks 8 hours a day, 40 hours a week. I know and understand how painful it is to use. But most of the time, the pain does not come from the engineering activity. In fact I love the few minutes I get to use my brain to work on something interesting. But instead, I spend hours staring at a progress bar to check out a file, release a file revise a file. The engineering change takes less than half a day and sometimes less than an hour. There are multiple instances of me completing my lunch while I check in an assembly. I do not understand the reason why the process is so slow, and I don’t think most engineers do either. There are countless blogs and technical assistance sites who’s whole job it is to provide support to a CAD Admin who is stuck. I always thought there must be a better way to handle files. I (foolishly) thought my university experiments had better, faster project management than this.

The version control software that my employer uses is the ingeniously named PDM. Its the default Product Management software that comes along with SolidWorks. Whenever I want to open an existing file from the PDM, it takes 20 minutes to open the file, another half an hour to checkout the file. Engineering, CI and Documentation takes less than a day. Then releasing the file takes few hours at least. The User Interface of SolidWorks PDM is unintuitive with unnecessary complications. Maybe I am not utilizing the full potential of PDM or I’m not using it properly but I think this can be done faster. The revision documentation I mentioned before is written by the engineer and cannot be verified without opening the file and comparing all the changes manually and visually. If the concerned assembly is large and has ~10-15 subassemblies with ~250-300 individual parts, SolidWorks starts to become unreliable with frequent crashes. In fact, when I started working, I kept a “SolidWorks Crash Counter”.

I have always been interested in the way software corporations handle their large and distributed code base without any (major) troubles. Git was made for Linux which is by far the most important Open Source and distributed project that thousands of engineers are working on at the same time. Programmers usually take responsibility of the deployment and running of their code. Mechanical Engineers do conduct PDCA and PFMA , FEA, CFD and CFM and other simulation methods to verify the operational ability of the parts and assemblies they have designed. Even though both domains use Distributed Version Control, there are fundamental differences in testing. If code runs and passes, it is good for production. (This is an obvious over-simplification, I know entire corporations exist to QA and test others’ code). But after a part is designed and the BOM of the object is finalized less than half of the total process is completed. After all, design is the easier part of Mechanical Engineering and the real problems start when you hit manufacturing. They differ much more when you are comparing NPD processes of the two domains. The version control process is relatively easier for code because code is plaintext which takes very less space. and to view the plaintext files any text editor would work. But 3D files take a lot more space compared to plaintext and the file types are proprietary. You cannot edit or even view proprietary file types if you don’t have the software. And the open source 3D CAD programs are good enough for hobbyists but nowhere near close to being equal in feature parity when compared with any mainstream CAD software. The situation has more or less been the same since CAD emerged and only now new ideas are coming out to at least try to solve these problems.

Interesting Solutions

KittyCAD (recently rebranded to Zoo) seems to offer some new ideas. They have a diff viewer chrome extension to be able to see CAD changes live in Github. Although I am not sure how it handles assemblies. Their software is relatively open source and they also want to go the plaintext route to store 3D files.


But I checked their product roadmap and it seems like they are going towards cloud based, web based, 3DExperience-ish route. Nobody likes 3DExperience. They claim to want to keep the files plaintext, lament the fact that most CAD formats are not interoperable but also want to create a new proprietary file format to enhance security. I am not sure if this applies just to the other metadata they want to store like material properties or also includes the 3D geometry.

Looking at other options, OpenSCAD is one of the solid alternatives out there that stores plain text 3D files and is completely open source. It definitely has a learning curve and differs a lot from traditional sketch based CAD. But projects like Openflexure have successfully used OpenSCAD and continue public development on GitLab. Openflexure project has successfully demonstrated that existing DevOps platforms can be used and can bring decentralization to hardware engineering

Openflexure project have documented their journey extensively and have essentially created a new pipeline which they call HardOps.

Although OpenSCAD is a wonderful piece of software, it is made for 3D printing and 3D printing only. 3D files are not the source for manufacturing, well drawn and drafted 2D drawings are. There appears to be no meaningful competition in this field to AutoCAD which costs thousands of dollars per year. AutoDesk’s recent clever ways to force users to pay is pushing users towards alternatives but for now there doesn’t seem to be any that covers the whole process including 2D yet. In the meanwhile I’ll be waiting for FreeCAD to get better and learn OpenSCAD.

References:

  1. https://cubehero.com/2013/11/19/know-only-10-things-to-be-dangerous-in-openscad/
  2. https://urish.medium.com/designing-3d-printable-mechanisms-in-openscad-5838dcb65b39
  3. https://hackaday.com/2018/11/14/mastering-openscad-workflow/
  4. https://www.techrxiv.org/doi/full/10.36227/techrxiv.15052848.v1
  5. https://ohwr.org/project/ohr-meta/wikis/home
  6. https://flowengineering.com/blog/digital-transformation-failing-engineers/
  7. https://zoo.dev/blog/tales-from-an-me
  8. https://zoo.dev/blog/mechanical-cad-yesterday-today-and-tomorrow#user-content-fn-8
  9. https://forums.cgsociety.org/t/cad-is-it-art/936722
  10. https://standards.nasa.gov/sites/default/files/standards/NASA/Baseline/2/2021-12-09-NASA-HDBK-0008-Inactive-New-Design-2021.pdf
  11. https://assets.ctfassets.net/c2mtbunjxyfe/576AcANtELHY1qzQXDQBpe/965235c909b093e6612f93780931d913/SpaceX_Systems_Engineering_Handbook.pdf