Types of Library Management
    • Dark
    • PDF

    Types of Library Management

    • Dark
    • PDF

    Article summary

    Types of Library Management

    The following categories are listed least-to-most sophisticated, but most businesses pick and choose a minimal mix of all of these.

    In-file design Libraries

    Most organizations start with an in-file design library. It’s often fully integrated into the schematic, PCB, and ECAD project files. This works for most smaller organizations as the overhead of managing a few PCBs per year is enough for a single engineer.



    Gratis (free as in lunch) and Libre (free as in licensing)

    All of the work, every time


    Fully manual

    Easy for teams without purchasing/planning

    Mistakes get propagated

    Different PCBs have different component data

    Designs diverge every PCB revision

    The longer you wait to organize, the more work it is to fix your components

    Ad hoc library: symbol and footprint files

    Separating the symbol and footprint information from the schematic and PCB files allows them to change independently of the PCB design. Without version control, centralization and a more formal process, these libraries often have the same problems as no libraries. Designers often go rogue and make their own libraries, defeating the purpose of having external library files.

    Library files containing symbols, schematic, footprint, PCB, and component metadata.

    Version controlled library files

    Version controlling external library files is such an easy and productive process to adopt, that it should be one of the first operations when starting a PCBA design. The design delays and production issues with component errors is worth the ROI on starting a minimal version controlled component library.

    Version control allows you to do small daily steps to incrementally improve your libraries.

    Here is an example workflow where a design engineer needs a new component, like an LVDS clock driver.

    Library files containing symbols, schematic, footprint, PCB, and component metadata.
    Version controlled library best practices
    • Separate files for component categories

      • They all have their own complexities

      • Smaller changes more often

      • Separate resistors from capacitors

      • Semiconductors by type

        • Microcontroller/microprocessor/FPGA/etc

        • RAM

        • Logic

        • Power

        • RF

      • Hardware by type

        • Connectors

        • Cables

        • Externals (i.e. SD card, battery, antenna)

        • Fasteners

      • Operations

        • Barcodes (2D, Matrix)

        • Stickers

        • Laser markings

    Challenges of simple version controlled libraries

    Component ordering attributes are often still embedded in the symbol files at this point. They have to be manually exported and then massaged into a format manufacturers can use. Even if the information is in separate “integrated library” files or database, there is often a manual and error-prone process involved.

    CI controlled libraries

    With the addition of Continuous Improvement (CI) Action Runners, you are able to bolt-on an automated component librarian:

    • Never sleeps, never sick, always sharp, never gets distracted

    • Follows process exactly

    • Fetches component data

      • Extended BOM + COGS

        • Single and multiple quantity scenarios

      • Availability and lead time

        • Generate fast/slow PCB assembly turnaround build plans

      • Automatic component alerts

        • Price changes

        • Lifecyle changes (End of life, NRFND)

        • Low quantity

        • Long lead-time

    • Generates where-used and usage data

    • Syncs with PLM and ERP systems

      • AllSpice.io → PLM/ERP

      • PLM/ERP → AllSpice.io

      • AllSpice.io ←→ PLM/ERP

    • Syncs with common databases

      • Relational: SQL, MySQL, MariaDB, PostGress, SQL Lite

      • Non-relational: NoSQL, MongoDB

      • GraphDB

    • Knows every programming language and framework

      • Works with existing tech stack

        • Python/Mojo/Django

        • C/Rust

        • Javascript/Ruby

        • Anything supported by Ubuntu 2024 LTS

    Here are some CI workflow diagrams

    Library files containing symbols, schematic, footprint, PCB, and component metadata.

    CI Actions

    CI is easy to understand. It’s a separate server that spins up a fresh software container (like Docker) and then runs any program in any programming language that you want.

    • Run Checks

    • Connect to external APIs to write or fetch data

    • Generates files (BOM, Drill, XY, FAB)

    • Generates documentation (compliance, utility, history)

    To learn more, visit our Actions CI/CD page.

    Was this article helpful?