The March issue of Design007 Magazine took on the topic of tribal knowledge. The magazine posed this question: Is tribal knowledge friend or foe? The articles generally discussed the value and concern of having a significant amount of knowledge locked into peoples’ heads. Articles also discussed how that knowledge can be transferred into automation for both repeatability, quality, and manufacturing cycle time reduction.
This year there has been a concerted effort to bring PCB fabrication, assembly, and semiconductor production from China to North America, India, Southeast Asia, and Europe as a way to reduce IP and economic security exposure. Multiple government initiatives, such as the U.S. CHIPS Act and proposed Printed Circuit Board and Substrates Act, are starting to address this.
This obviously makes sense due to the existing global political environment. As a byproduct of this transition, I am semi-regularly contacted with requests for support in building and defining new factories, improving quality in new factories, or providing names for individuals with these specific skills.
Unfortunately, the number of experts who hold onto this tribal knowledge is decreasing. This seems to be a significant issue for the proposed expansions. Where will this information come from? Is there another way to transfer this expertise without using this dwindling human tribal knowledge?
I’d like to focus on just the design-to-manufacturing data transfer component.
Currently most companies require that humans physically read their design requirements and then manually type them into their engineering/CAM systems. At first you may think that I’m crazy to make such a statement. No company has a specification that states, “The manufacturer shall manually read the design requirements prior to entering them into their systems.”
I am correct, though. Studies have shown that more than 80% of design data sets transfer partial design information as a PDF file (or Gerber layer) that requires a human to read and interpret this data. This is, in effect, a de facto requirement. An existing manufacturer is required to take an experienced operator, with tribal knowledge offline, to train a new employee on how to interpret the notes, discrepancies, tolerances, stackups, design intent, revision verification, etc. This training period typically takes up to one year to get to a basic understanding of what to watch for and how to intelligently propose potential solutions to the customer. To be considered an expert, it typically takes to up to five years for an experienced product engineer to receive and resolve the thousands of issues in data packages.
There are probably only a few hundred front-end engineering experts in North America and probably even fewer in the EU. So, where will the new facilities get that expertise? There aren’t a sufficient number of training classes or courses in available to teach new potential employees in colleges and universities.
How can we mitigate this crisis? The first step is for companies to quit sending manufacturing documentation that requires human intervention. This can be accomplished by using intelligent data formats, such as ODB++ (from Siemens) or IPC-2581 (from IPC).
These formats can eliminate the following, often conflicting documents.
Fabrication Drawing
The following fabrication drawing technical information can be embedded in an IPC-2581 file:
- Board outline dimensions and tolerances
- Stackup (Such as thicknesses, material/AVL, impedances, loss, and tolerances)
- Plating and surface finish specifications/locations (These can be assigned to specific nets, pads, etc.)
- General notes
- A drawing number and revision is not required since there won’t be a drawing
- The drill table (This can be extracted from the file)
- Cavity size, tolerances, and orientation
- Embedded component location
- Rigid-flex regions and flexible shapes and bend radiuses, etc.
- Assembly placement information
A drawing can be created from the data, if required. There are several excellent software packages currently being used.
Netlist
Netlists are not required to be sent. The netlist was created to verify that EIA-RS-274-D files were transferred correctly due to errors that were encountered due to merging the separate D-Code file. Intelligent files generally do not have netlist issues, except for intentional same net shorts, which is a defect in the IPC-356 file format but are not a real defect. (This was fixed in IPC-2581.) Incoming netlist comparison to the intelligent file graphical data is not required. Netlists that are required for electrical testing can be extracted from the IPC-2581 file.
Stackup Drawing/File
The stackup information and impedance specification is incorporated in the file, along with the tolerances. The proposed stackup information can then be included into an IPC-2581 file and sent back to the designer in the same file for direct comparison. No stackup structure, via structure information, or material is required to be sent as a picture on the fab print or in a separate Excel or PDF file.
Bill of Material (BOM) /Approved Vendor List (AVL)
A separate spreadsheet is not required to pass component BOM and AVL information. This is incorporated into the IPC-2581 file, then extracted from the file, and passed automatically to the CFX database.
There is a significant amount of information that can be incorporated into the intelligent file formats. In turn, this eliminates conflicting information between files. It reduces the number of experts required to train these new operators to interpret the design and manufacturing.
Teams that I have been involved with for over 20 years have implemented design transfer packages that could 100% be transferred without human intervention. Both ECAD and CAM software are commonly available. Our industry needs to adopt this methodology to reduce the future critical resource issue that these new facilities will face just for data transfer.
Dana Korf is the principal consultant at Korf Consultancy LLC.
