Should The BOM Specify Firmware Versions?

BOM stands for Bill of Material, which can be translated as a material list, material inventory, or parts list. BOM contains information about the material names, quantities, models (suppliers), material codes, etc., of the components used in PCBA, making it a crucial document for guiding PCBA assembly. The contents of the BOM are often represented in tables. Each row of the table represents a single material, which can include quantity, manufacturer model, specification summary, and position number. Sometimes, it is also necessary to include the name of the connection pattern (package) used. Each material must have a code, and this code must remain unchanged throughout the process. The bare PCB, as a material for PCBA, is usually listed separately in the BOM. Whether to specify the firmware version in the BOM can sometimes be a controversial issue. Proponents argue that it should be specified because firmware may correspond to different material formulations; opponents believe that firmware is developed in parallel, making it difficult to freeze the version before production, and it also increases the workload to support version queries in DFT design code. I believe that the BOM needs to specify the firmware version. If the firmware cannot be frozen, it indicates that development and testing are not mature, and thus manufacturing cannot be discussed. Of course, for companies that prioritize quality but actually prioritize shipping, people like me are not welcome. I can only say that some rules are particularly simple, and ignoring them will lead to suffering. In actual work, changes to the BOM can happen at any time. In a manufacturing company I worked for, the BOM would change right up until the product went into mass production. Sometimes this is due to testers discovering previously unnoticed issues, prompting urgent corrections in development, and changing materials is the fastest way to address this. Other times, adjustments in the process formulation require changes to the pin shaping and packaging requirements of the materials. There are also times when there are design changes from material suppliers, changes in delivery times, or quality risks that need to be resolved for other products from the same supplier. Additionally, there are times when procurement personnel need to insert alternative models to deplete inventory or reduce dependence on a single supplier. There are countless such scenarios. The content of the BOM strives for accuracy. Firstly, it is best to refer to software code and implement version management. The BOM version should ideally match the assembly drawing. For some simple products, it is common to write assembly requirements in the BOM to distinguish different BOMs. I believe that if the number of materials in the BOM is below 20 items, this approach is acceptable. However, if the BOM is larger and contains more materials, it is better not to cut corners and to mark and control by version. Secondly, the accuracy of the BOM should be based on the accuracy of the company’s material database. Taking the company I worked for as an example, they first established an electronic component library based on the Siemens PDM system, which was later upgraded to a PLM system, managing over two thousand materials with a custom 10-digit code. The PLM system synchronizes with the Cadence CIS system backend. This architecture is feasible; however, due to the lack of professional management, with multiple sources of authority, the database fails to maintain accurate data element content during upgrades and expansions, and changing these elements involves a complicated review process. As a result, the vast majority of engineers only focus on their immediate tasks, ensuring model accuracy with Cadence’s local attributes while neglecting the integrity of the database. This situation leads to issues occurring once or twice a year that affect collaboration.Author: Electronic Knowledge Community, Source: Breadboard Community