The evolution from Gerber to Industry 4.0 is well on its way.
Fujitsu Network Communications, a telecommunications services and equipment supplier based in Richardson, TX, is a founding member of the IPC-2581 Consortium. We quickly saw the potential of IPC-2581 to not only streamline our existing fabrication and assembly processes, but to go beyond them to provide a coherent interface to our PLM and ERP systems and our downstream manufacturing processes. We were one of the pioneers of its early adoption. We have now had PCBs successfully fabricated using IPC-2581, ranging from complex optical interfaces with high SMT pin and layer counts, to largely through-hole and mechanical-based controller boards. All three of our regular fabricators are able to accept and fabricate successfully from IPC-2581.
The digital data transfer evolution at Fujitsu started with Gerber, as with so many others. We created our own script to generate each individual Gerber file per layer, generated the separate netlist file and any other drawing and/or text file required, and bundled everything into a package to give to our fabricators. Our fabricators in turn developed their own scripts to import our package.
When our layer naming convention expanded or changed, the script had to be changed to match, and we had to communicate the change to each fabricator so their scripts could be kept in sync. We imagine the fabricators spent a lot of time maintaining scripts for each customer. As a new Fujitsu employee back in 1996, I was taught “the way of the script” and how to maintain it. But even with a script, additional manual steps were still involved, which were sometimes forgotten. If there was a last-minute change to the design, care and time had to be taken to regenerate all affected Gerber files, netlists, and/or supporting documents that made up the fab package.
Along came ODB++. We immediately saw the chance to automate our fabrication process. We switched from Gerber to ODB++ and never looked back. That was 20 years ago. The self-intersecting polygon issue in artwork layers was not solved by moving to ODB++, but apart from that, we had many years of error-free fabricating, and couldn’t understand why others wanted to stay with Gerber. We create our own fixed-width panels containing one to n boards, to optimize our in-house assembly line, so a script was developed to automatically create the panel in Valor and generate the ODB++ .tgz package to be sent for fabrication. We thought we had an efficient fab process. And yet…
Fabrication data are just one piece of the design data puzzle, along with the assembly data, bill of materials (BoM), test data, stencil data, mechanical data, etc. We still had to scramble due to last-minute design changes to ensure the revisions of all the pieces stayed in sync. We used a proprietary assembly data format, which required customizations in CAD for library and export, and custom imports to PLM, all of which had to be maintained. The ECAD BoM was still manually merged with the MCAD BoM when entered into ERP, and various formats were needed for downstream processes: stencil generation, quality check, AOI, test, etc. Despite the automation in our fabrication process, we still communicated stackup requirements in emails and text files, and received proposals back in .jpg files. For the digital age, this seemed antiquated. If only there were a single file that could be used for everything – fabrication, stackup requirements, assembly, BoM, test, stencil – that synchronized everything by generating it all automatically at the same time, and was based on an industry standard schema that other systems like PLM could read and interact with. Enter IPC-2581.
When we learned of the great potential of IPC-2581, we were delighted to cofound a consortium to promote its use. We immediately set about to validate the format. Our CAD tool vendor, Cadence Design Systems, was a consortium cofounder too, and provided the IPC-2581 export capability out of the box at no extra charge. We graphically compared IPC-2581 artwork with our known good artwork, and found no unresolved differences, except for a thermal rotation issue in ODB++, which we had not noticed before. To ensure our CAM tool was aligned with IPC-2581, we switched to VisualCAM from Wise Software. Wise helped us replicate, and then surpass, our panel generation process (more on that later). We found that because IPC-2581 is XML-based, we could use standard programming techniques such as XSLT transforms to:
1) Augment the BoM data in the IPC-2581 file with non-CAD properties from our PLM system.
2) Merge the ECAD BoM with an IPC-2581 export of the BoM from our MCAD tool.
3) Describe a hierarchical BoM using IPC-2581, of the multiple boards that make up a product, to automatically import and process that whole product into ERP.
4) Export on-demand fabrication and assembly mode IPC-2581 files, which are dedicated subsets of the full file, to limit exposure of design IP.
FIGURE 1 summarizes the Fujitsu IPC-2581 file generation flow.
Figure 1. Fujitsu IPC-2581 file generation flow.
As part of our validation process, we prepared three designs to submit for fabrication and assembly. The first (TABLE 1) was a 20-layer Class 3 board with more than 15,000 drilled holes, more than 4,000 SMT components, and single-ended and differential-pair impedance control on 12 layers. The second was a 12-layer Class 3 board with 1857 drilled holes and single-ended impedance control (TABLE 2). It has 510 total SMT parts. The third was a 12-layer Class 3 board with 939 SMT parts, more than 3,800 drilled holes and single-ended and differential-pair impedance control (TABLE 3). Each was submitted to fabrication as a single file, and required no additional communications, iterations to explain, edit, and update the design data. Each board came back from fabrication built correctly and passed all validation tests.
Table 1. Fujitsu Design 1
Table 2. Fujitsu Design 2
TABLE 3. Fujitsu Design 3
Improvements Due to IPC-2581
Generation time. We gathered metrics of our “send to fab” process using IPC-2581 and VisualCAM versus our previous process using ODB++ and Valor. The average time savings to export from our CAD tool (Cadence Allegro), import into the CAM tool to produce the panel, and export the IPC-2581 file from that was 22 minutes per design, an average saving of 75%. This may not sound like much in an overall design cycle, but we repeat the process an average of three times per design, due to late design changes or fixes as a result of DfM reviews, etc. It comes to an average of just over one hour total savings per design. Then consider how many designs we develop in over a year. That’s a lot of hours saved. (If we were to compare the IPC-2581 process with our original Gerber process, the savings would be much greater.)
Going paperless. Using VisualCAM we can easily add tolerance to dimensions on a drawing layer, and that layer is then embedded in the exported IPC-2581 XML. This can then be viewed and printed from the free Wise 2581 Viewer. Similarly, we can describe the v-scores for panels, including associated properties such as web angle. We can generate these data automatically by importing IDF data from MCAD that contains the v-score locations. We therefore no longer need to create and include a separate PDF drawing of board dimensions and v-scores. The separate drawing had its own revision that had to be kept in sync with the other data.
IPC-2581 also supports embedded impedance requirements, material properties (dielectric constants, surface roughness, etc.), manufacturing notes, and other board information such as compliance. Some CAM tools have a utility that augments stackup data imported from CAD. FIGURE 2 shows snapshots of the VisualCAM Stackup Editor detailing the information captured. All this stackup information is embedded in the exported IPC-2581 XML file. We can either include it with the fabrication artwork or generate a “stackup only mode” export. This eliminates the need for the text file that had to be created to contain all this information for our old process.
Figure 2. IPC-2581 Stackup Editor example.
The Fabricator’s Point-of-View
Gerber. Fabricators develop their own scripts to import Gerber data supplied by their customers, the OEMs. But they need a different script per customer because:
1. The layer type of each Gerber file is only determined by the name given to the file, and each customer can have different naming conventions.
2. Each customer has additional drawing and text file requirements.
3. Even different locations of the same large company can have different naming conventions and file requirements, so must be considered different customers in terms of script support.
Some customers have been supplying Gerber data the same way for years, which they say works, so why change? But it is the fabricators who bear the brunt of supporting all the different customer import methods and naming conventions thrown over the wall, and learning new methods and conventions as they take on new customers. They don’t complain because they don’t want to lose customers. But if the customers used the single, consistent file format of IPC-2581, with layer types defined independently of name, and material properties and drawing data embedded in the file, then the time gained by not having to support all the scripts could potentially be passed on to the customer. Indeed, there is now at least one manufacturing services company who charges extra if data are not supplied in IPC-2581 format.
Bidirectional stackup exchange. Traditionally we manually enter our initial stackup requirements into a text file or spreadsheet, which fabricators then manually enter into their stackup analysis tool. They then send back their proposal in a .jpg or .txt file, which we have to manually enter into our CAD tool. This process could be iterated several times before a result is agreed upon, so there is a lot of manual entry and commensurate potential for error. With IPC-2581 we can use Allegro or VisualCAM to send a stackup mode IPC-2581 file containing stackup configuration and material properties, which fabricators can automatically import. The fabricators want to provide us with an IPC-2581 file of their proposal, which we can automatically import.
Embedded impedance requirements and notes. Fabricators also have to spend a lot of time entering controlled impedance constraints, and making sure all notes and general requirements are covered and understood. This has been manual entry, which is prone to human error. Waiting for clarification from the customer causes even more delay. They are happy to have the opportunity to automatically import these data using IPC-2581.
What about Gerber X2? I asked one of my fabricator contacts if they supported Gerber X2. I was told their systems could support it, but they had not received any data to confirm that. They said that if they did receive Gerber X2, they would treat it like normal Gerber, because the tools and scripts they have can already read basic Gerber, but not any additional properties.
Conclusion
I have seen articles on fabrication format comparisons resorting to format bashing. I am not claiming other formats are bad. Gerber and ODB++ have served us well as a fabrication format at the time we used them, and serve others well today if that’s all they need. Both Gerber and ODB++ have been enhanced, seemingly in response to the rise of IPC-2581. Gerber became Gerber X2 with additional properties for fabrication, but fabrication is all it will ever support. ODB++ support for assembly and test was introduced, but uses disparate file types embedded in a tar ball, which is essentially the same as supplying separate files in terms of content import and synchronization. But if, like Fujitsu, you want to fully embrace Industry 4.0, and strive for all your design process deliverables being communicated digitally and automatically, with no “paper” (PDF, text, etc.), then more is needed. IPC-2581 is the only format built from the ground up to provide machine-readable data for all major design functions: BoM, fabrication, assembly, test, stackup, and stencil. Being XML-based it can interface to other systems, such as PLM or ERP, or even a system not yet thought of. IPC-2581 files can be subdivided by function mode to provide only the minimum IP required, or augmented with additional data by tools or systems further downstream in the design process. With so many companies now supporting IPC-2581, the chances are the tools or vendors you use can support it, usually at no extra cost.
Moving to IPC-2581 from another format requires change, and there is no denying change can be painful at times. But as business environments change, always toward “more in less time,” companies and their processes must change to survive. IPC-2581 will be able to interface with IoT or machine-to-machine formats that are becoming prevalent, further extending the digital thread to the manufacturing floor. IPC-2581 is the CAD data exchange format of today – and the future.
Chris Shaw is senior design automation analyst at Fujitsu Network Communications (fujitsu.com/us) and co-chair of the IPC 2-16 Product Data Description subcommittee; This email address is being protected from spambots. You need JavaScript enabled to view it..
