kicad-developers team mailing list archive
-
kicad-developers team
-
Mailing list archive
-
Message #04838
BOM processing - a use case
Since there's more focus on the BOM recently, I thought I'd
share a use case that shows what one can do with the existing
BOM: for gta02-core, I've written an external BOM processing
system that associates BOM entries with items from inventories
and generates "shopping lists" optimized for volume discounts.
Inventories tell the system where a certain part can be obtained
and at what price. E.g., a distributor's catalog or local stock.
To match parts, the system uses various strategies. If the value
matches a part's ID, that part is taken. If not, a user-provided
set of substitution rules is applied. Then a value match is
attempted again.
If we still have no part, the system tries to match
characteristics. For this, the rules determine what kind of part
we have (e.g., a resistor), then extract the characteristics
given in the schematics (e.g., R = 4.7 kOhm), and provide
defaults for those not given (e.g., tolerance <= 5%). With this
information, it searches tables that list the characteristics of
parts.
There are also equivalences. Those can be equivalent parts, e.g.,
the same chip from a second source; different names of the same
part, e.g., a vendor's and a distributor's part number; if you
wish, project-specific substitutions of not truly equivalent
parts; etc.
Last but not least, parts can also have a textual description,
which appears in the "shopping list" and which can be used to
make crudely annotated schematics that show for each component
what part has been selected (for review.)
The workflow (with a few project-specific extras):
http://people.openmoko.org/werner/gta02-core/bom-workflow.pdf
The BOM processing system:
http://svn.openmoko.org/trunk/eda/boom/
A project-specific environment:
http://svn.openmoko.org/trunk/gta02-core/bom/
An example of a "shopping list":
http://svn.openmoko.org/trunk/gta02-core/orders/ee-bom-fic-20100208.txt
An example of the annotated schematics:
http://people.openmoko.org/werner/gta02-core/gta02-core-bom-all.pdf
If you're looking for reasons not to like it, here are a few:
- it's all written in Perl,
- to tie things together for a project, you use a Makefile (1),
- the substitution rules are vaguely inspired by sendmail.cf (2),
- the "user interface" is made up of the command line and your
text editor.
There are also some misfeatures in the functionality, e.g., it's
blissfully ignorant of shipping cost, lead time, etc.
(1) The one we have is about as bad as it gets:
http://svn.openmoko.org/trunk/gta02-core/bom/Makefile
Some of the more obscure bits, like INTERPRETATION, exist to
deal with a number of idiosyncrasies I wouldn't wish on any
other project.
(2) Well, I wimped out on the syntax:
http://svn.openmoko.org/trunk/gta02-core/bom/gta02-core.sub
Now, this is a system that's flexible enough to handle complex
projects. It's fully automated, so changes in the schematics
propagate all the way to the shopping lists without any user
intervention. (That is, unless you need to introduce new parts
or such.)
Its functionality and complexity probably goes beyond what you'd
want to have live inside KiCad, but the BOM export provides all
the data this needs from KiCad. (Field names will be a nice
improvement, taking some of the guesswork out of the
substitutions.)
- Werner