On an August evening in the sky above a California desert, a skydiver leaped from the safety of an airplane without a parachute. His target was a square net positioned on the desert floor below. Traveling at terminal velocity, the skydiver performed a slight roll just prior to impacting the net to land on his back. In the end he arose, unharmed and was greeted by his family and friends.
The question I pose is when did this skydiver take into consideration how this leap was going to end? Two things that were clear: there was an endpoint and he needed to protect his life. There were a number of possibilities and he needed to commit to one with very limited flexibility. The decisions along the way were very much a matter of life and death. Do you feel that you take a similar leap of faith whenever you commit your design into manufacturing? If you do, or this is even remotely how you feel, then it is time to evaluate the reliability and effectiveness of your manufacturing data-exchange.
When a PCB design is ready for manufacturing, the process of moving the data model into manufacturing is often referred to as “shift-right”. The objective of a modern shift-right data model is to enable the exchange of manufacturing process requirements beyond what traditionally is communicated using legacy formats. In the case of PCB manufacturing, the traditional legacy exchange method breaks down a complex design into compartmentalized and disconnected data segments representing design layers, drilling requirements, net information, component locations and orientations, BOM, etc. Once received by a manufacturer, all need to be reunified into a data model specifically implemented for the designated manufacturing requirements. This would be equivalent to giving someone an illustration of roads and freeways accompanied by a separate list of route names and expecting to be able to arrive at an agreed upon location. However this is what happens day in and day out when it comes to PCB manufacturing using traditional legacy formats.
The ODB++Design (ODB++D ) product model provides a fully integrated map, a GPS generated route if you will, clearly communicating what is required to successfully produce a PCB by eliminating the possibility of misinterpretation. As technology needs continue to evolve, so does the ODB++D product model. Over decades of use, the ODB++D product model has expanded to include process requirements such as embedded components, rigid-flex and flex materials, and design and production stackups, to name a few. If you ever elect to skydive I suggest that you use a parachute and for a similar reason when releasing a design into manufacturing rely on the ODB++D product model because it is accepted by most manufacturers, second only to the traditional formats, and supported by every major PCB manufacturing software solution available today.
Ensuring your design is properly prepared for production is just as important as it is to ensure your parachute is properly packed prior to a jump. The complexity of a planned jump paired with the skill of the skydiver is not much different than utilizing a design’s complexity to determine possible manufacturers having different process capabilities and in both cases it incredibly important that the combination works well together. Fortunately for PCB manufacturing we have PCBflow which connects your design to a number of PCB fabricators and enables the validation of a design prior to shifting the design to the right and into production.
Looking back at the shift-right dilemma from view of a manufacturer is kind of like setting up the net to catch the skydiver. I would want the manufacturing data to arrive safely intact, but just in case I would setup the net and hope for the parachute to work. So when asked if an ODB++D product model is acceptable, the confident response would be “Yes, of course.” When asked if Gerber, Excellon, IPC-356 netlist and component placement list is acceptable, the regrettable response is “Yes, but…” In one case the design lands reliably into manufacturing safely, but in the other we all hope you hit the net. Which method of landing would a manufacturer having a real choice elect to use? How about you?
When your organization is ready to move to a modern exchange of shifting-right an intelligent data model, I believe the ODB++D product model is the best choice. You can ease into the process like your first tandem jump by validating that the ODB++D product model matches the traditional data sets and send both to the manufacturer. This will build confidence in the exchange until one day soon when the only data model ever exchanged is based solely on ODB++D.