GitPLM -- PLM (product lifecycle management) in Git

Projects
#1

Hi, I recently needed a way to manage information for a handful of designs for one of my customers, so started scratching out a tool/process for this.

There are other tools out there (1 2), but would like something that is a little more general, works with multiple CAD systems (PCB and mechanical) and usable at a slightly higher layer multi-level BOMs, product assemblies, etc.

I think Git is a generally useful tool that can be used in many workflows beyond software source code that require collaboration and review, and have been experimenting with using it in different ways. Perhaps it can be used to manage PLM data changes and review.

Ideas/feedback welcome.

3 Likes
GitPLM – PLM (product lifecycle management) in Git
Test for wiki add to 15
GitPLM – PLM (product lifecycle management) in Git
Making a good BOM is not simple
#2

Neat! I’ll take a closer look when I have time. I think having an open PLM tool and workflow that is designed for Git and compatible with KiCad is great. I think using proper PLM techniques is a good idea even for tiny companies or individuals making PCBs – if your products will have any lifetime at all, using internal part numbers (HPNs as Cliff calls them) in your CAD tool instead of manufacturer part numbers is a really good idea, but to make that easy you need a tool to manage the mapping between internal part numbers and actual purchasable items (manufacturer part numbers) over time, and this is one of the important things a PLM system does.

#3

This is very interesting! I will have a closer look too see in this can fit in my workflow. Or at least get inspiration for functions to add to my own scripts.

#4

Any thoughts on what to call internal part numbers. I’m currently using HPN (house part number), but that might be confused with board house or assembly house. Another options is IPN (internal part number). Thoughts? What is typically used in industry?

#5

A few more features:

v0.0.2

  • support for adding/removing KiCad BOM items. See
    PCB-019.yml for an example of syntax.
  • misc cleanup
  • output BOMs are sorted by HPN

v0.0.3

  • write log file when processing BOM (see
    PCB-019.log). This ensures any errors are
    captured in a file that is automatically generated and can be stored in Git.
#6

I like internal part number (IPN) vs. manufacturer part number (MPN). Pretty much self explanatory.

#7

“internal part number” seems OK to me as a long-form name. We just call them “part numbers” for short most of the time (i.e. “part number” is assumed to mean internal part number, if you meant the manufacturer’s, you would say MPN)

1 Like
#8

Thanks for the feedback on HPN vs IPN – plan to change the field labels to IPN soon …

#9

v0.0.4

  • switch from HPN (house part number) to IPN (internal part number) (#11)
  • implement Github CI (runs tests in PRs) (#13)
  • change -version commandline switch to print application version
  • add -bomVersion to specify BOM version to generate (used to be -version )

v0.0.5

  • add badges in readme
  • fix missed error check
1 Like
#10

New gitplm release:

v0.0.7

  • support multiple sources of parts in partmaster – simply put on separate
    lines. GitPLM will select the part with lowest Priority field value. Other
    fields like Description are merged – only need to be entered on one line.
    See CAP-000-1001 in examples/partmaster.csv for an example of how to do
    this.
2 Likes
#11

v0.0.8

  • if BOM includes subassemblies (ASY, or PCB IPNs), also create a purchase BOM that is a recursive aggregate of all parts used in the design. This BOM is
    named CCC-NNN-VVVV-all.csv
1 Like
#12

v0.0.9

  • fix bug in log file name – should sit next to source BOM so we can track
    changes
2 Likes
#13

I’m thinking of changing the PN format from CCC-NNN-VVVV to CCC-NNNN-VVVV.

Reason is this would allow for ~10,000 major part types in each category. This would give enough numbers to allow this format to scale to large organizations and be re-used across multiple organization – kind of like a UPC code for components. I don’t think the increase to 4 digits hurts readability any, and is perhaps more consistent.

This also begs the question should CCC be CCCC …

Could also allow any number of characters in each section. Then sorting becomes more complex, but that may be most flexible and best long term, and writing a smart sorter would not be that hard.

#14

v0.0.10

  • allow partmaster.csv to life in any subdirectory instead of having to be at
    top level. This allows parmaster to live in a Git submodule.
2 Likes
#15

v0.0.11

  • add support for checked column. This value now gets propogated from the
    partmaster to all BOMs and can be used for a process where a part information
    is double checked for accuracy.
#16

v0.0.12

  • fix issue BOM lines with zero qty not being deleted (#28)
#17

v0.0.13

  • in output BOMs, move MPN and Manufactuer columns left. This makes it easier
    to import BOMs into distributor web sites like Mouser. (#30)
1 Like
#18

I just updated the documentation with some diagrams and more rationale for the tool:

Thoughts/feedback welcome.

1 Like
#21

New release:

v0.0.14

  • support PCA assemblies
1 Like
#23

v0.3.0

  • support hooks, copy, and required sections in release configuration (yml) file.
  • rewrite README.md
  • gather up manufacturing assets for all parts we produce.
1 Like