Issue link: https://iconnect007.uberflip.com/i/1163814
42 DESIGN007 MAGAZINE I SEPTEMBER 2019 model for any of the content to be available for application use. The single-file approach is simpler and less prone to error. However, the consumption of the product model in either form is transparent to the user of manufactur- ing solutions, making either choice no more or less complex than the other. As described earlier, the product models are getting larger in data size at an amazing rate. A single PCB product model reaching the size of over 200 megabytes can be a daily occur- rence. When integrating a product model into other applications, the responsiveness of the results is typically a measure of success. When a product model is divided into files that con- tain content intended for specific purposes, the integration effort is only required to read a tar- geted portion of the complete product model. This improves application response time and encourages the further use of the product mod- el. Other approaches may require an applica- tion to transverse a large portion until the data being requested has been located. An example is knowing the location of a spe- cific component reference designator on the top side of the product model and the location of the tooling holes from a specified drill layer within a product model. In the case of ODB++, the information would be located in two much smaller files specifically for this purpose: one file would contain the location of components and the other for the location of the drills. In other cases, the integration would need to read and possibly rationalize a larger portion of the product model than necessary to obtain this same information. There are many cases where the ODB++ prod- uct model content has become part of a larg- er release-to-manufacturing process in cooper- ation with solution suppliers and along with existing adopters of ODB++. Bob Dylan once said, "There is nothing so stable as change." The evolution of design and the change in the manufacturing processes since the first release of ODB has been significant. Every change in ODB++ today is scrutinized under a set of cri- terion. At the base is whether a change in the for- mat will maintain backward compatibility. The ODB++ format can do that because the struc- ture of the data is such that one change is iso- lated for a designated purpose. If the change does not result in the loss of backward com- patibility, the change can go in an update or a minor release under the same version num- ber. Changes that affect backward compatibil- Figure 6: Examples of ODB++ outputs.