Having a shared component library can save time, reduce mistakes and make designs more consistent. Without proper management, however, it can create its own set of problems that may not be obvious at first.
As a Formula Student team in its first year, we at JKU Racing have learned this lesson the hard way throughout several PCB development cycles. Although there was no single problem that caused the entire system to fail, we accumulated a growing collection of small issues that hindered an effective design process.
For example:
- New components were created whenever they were needed instead of reusing existing ones, leading to a large collection of nearly identical library entries and physical parts.
- Designers had no way of knowing which library parts or footprints had already been confirmed to be correct.
- Library entries were modified to fit individual projects, without considering the effects of these changes on other projects using the same parts.
The main takeaway from our first season in Formula Student was therefore:
A shared part-based library can be a valuable tool for streamlining design and purchasing workflows, but it requires proper management to remain effective.
Is this new part really needed?
Imagine the following situation: Designer A uses a 24 V to 3.3 V regulator that requires 10 uF of input capacitance and 2.2 uF of output capacitance. As there are no suitable options in the component library, Designer A creates a 10 uF, 35 V capacitor and a 2.2 uF, 10 V capacitor.
Some time later, Designer B uses a 5 V to 3.3 V regulator. Its typical application schematic shows a 10 uF, 20 V input capacitor and a 1 uF, 10 V output capacitor. As neither exact part exists in the library, Designer B creates two additional components that match these requirements.
Repeat this process few times and you may end up where we did: with no space left in our SMD storage box, even though it only contained maybe 20 genuinely different capacitance values. Why? Because we managed to collect up to five different variants of e.g. a 10 uF capacitor that could easily have been consolidated into only one or two different components that would have covered most applications.
By copying and pasting circuit sections between projects from different designers, one may even end up with several entries in the bill of materials that are electrically and mechanically equivalent, differing only by manufacturer or part number.
The problem in the example given above was not that designers had selected incorrect capacitors. There simply was no process for managing the creation of new components or choosing existing components. Looking at Designer B’s case again, they probably could have reused the 10 uF, 35 V capacitor created by Designer A. When taking a closer look at the datasheet used by Designer B, rather than simply copying the typical application schematic, we might find that it specifies an allowable output capacitance between 1 uF and 10 uF, so they could have even reused Designer A’s 2.2 uF output capacitor.
To avoid situations like this in the future, we will implement a clear process for selecting existing components and creating new ones.
Defining preferred parts
One of the most effective improvements is to establish preferred components, especially for frequently used parts such as:
- Decoupling capacitors
- Common resistor values
- Indicator LEDs
- Standard diodes and transistors
- Connectors
- Microcontrollers and communication transceivers
- Voltage regulators
A preferred part should be chosen so that it accommodates the most commonly encountered operating conditions with some margin. There is, however, little benefit in selecting components that are significantly overrated for their intended use, as this may unnecessarily increase component size and cost. The exact choices do not need to be ideal for every possible application, but should consider factors such as capacitor DC bias, temperature range, availability, cost, etc.
When choosing components for a specific circuit, one should consider the possibility of combining existing library parts in series or parallel to achieve a required value. For example, if the calculated series resistor for an LED is 130 Ω, existing library entries for 100 Ω and 33 Ω resistors can be combined to obtain 133 Ω. Small deviations from theoretical values like in this example will be insignificant in many applications and avoid having to introduce new components every time a new value is required.
Combining existing components like this does, of course, come with additional board space requirements and costs, so under certain circumstances, creating a new component may still be preferable. Further reasons that may justify the creation of a new part include:
- Existing parts do not provide the required voltage or power rating, precision, temperature stability, etc.
- Achieving the required value would require combining an unreasonable number of existing parts.
- Mechanical constraints require a different package.
- The application requires special characteristics, e.g. C0G capacitors or automotive qualification.
- Existing parts are obsolete, unavailable or disproportionately expensive.
In general, “preferred parts” should be treated as exactly that: preferred defaults, not mandatory choices.
Creating new components
Before creating a component, the designer should ask themselves:
- Has the function I am trying to achieve been implemented before? If so, which parts were used, and can that implementation be reused or adapted?
- Does a suitable part for my use case already exist in the library?
- Can I combine two or three existing parts to match my requirements?
- If the available value differs slightly from the calculated value, will the difference affect circuit performance?
- If no existing parts can be used, what is the requirement that prevents this?
- When creating a new part, how can I select its specifications so that it may also cover future applications?
To make it clear to every designer whether a part has been successfully used before or if it has only recently been created, every library entry should have a lifecycle state. A minimal system could use two states:
- Draft / Untested: The part has been created, but has not been verified on real hardware.
- Proven / Tested: The part has been successfully assembled and confirmed working on a real PCB.
To catch mistakes early, it can be useful to introduce a third state which requires independent review before a PCB using the new part is allowed to be ordered:
- Draft: Created, not ready for manufacturing.
- Reviewed: Checked by a second designer against datasheet specifications.
- Tested: Successfully assembled and tested on real hardware.
Using this workflow, new parts can be integrated into the library while the team retains control over which parts are added and which parts can be trusted.
Applying changes to existing components
Let’s go through another example that showcases a different failure mode we encountered with our existing system.
Suppose Designer A notices that their schematic would look cleaner if the D+ and D- pins of a USB transceiver were swapped in the schematic symbol. So they go ahead and change the library component accordingly without thinking much of it.
Later, Designer B decides to finally create the layout for a schematic they created two weeks earlier - which happens to use the same USB transceiver. Before starting the layout, they update all components to their latest version, just for good measure. What Designer B does not know, however, is that in doing so, they have effectively swapped D+ and D- in their design due to the symbol change introduced by Designer A after Designer B had already created a schematic using the old symbol. As a result, the USB interface of Designer B’s PCB may exhibit confusing communication problems or fail completely. As one can imagine, if Designer A had instead decided to swap some supply pins, the consequences may be even more serious.
Luckily, this failure mode can easily be remedied by the system introduced above by simply ensuring that every change to a library component means its lifecycle state will be set back to “Draft”. Assuming the subsequent re-review is performed carefully, issues like the one we just introduced should be caught easily.
What is required for this system to work?
Of course, all the measures introduced above are ineffective if designers create new components and immediately mark them as “Reviewed” or even “Tested”. For very small teams, it may be sufficient to ensure that all designers follow the agreed management process. As the team grows, however, the ability to change a component’s lifecycle state should be restricted to a small group of “librarians”. These library maintainers should be responsible for:
- Reviewing new entries.
- Checking for duplicate or unnecessary parts.
- Updating lifecycle states.
- Assessing changes to existing components.
Conclusion
A shared component library based on actual orderable parts can streamline schematic design, PCB layout, purchasing and inventory management. To work effectively, however, it requires clear component selection processes, lifecycle states, independent reviews and controlled change management. Without these measures, the library can and likely will gradually become a collection of duplicates, obsolete parts and undocumented modifications.