02/17/15 5:05 am Mars Int.
In this series we have discussing the important role that good documentation control has in protecting your intellectual property. Losing control of your documentation package to the manufacturer or engineering firm that helped design your product is problematic to say the least. Limited supply mobility, costly re-engineering, and rights protection issues are all too common results of not tightly securing your documentation package.
The following are some of the basic electronic files that need to be included in the documentation package.
A schematic shows all components and interconnections. It is very difficult and error prone to reconstruct by reverse engineering the product, so it is important that this be maintained. As with 3D CAD data you should keep this in the original native format as well as PDF documentation that anyone can read.
The Gerber files define the bare printed circuit board, including traces, holes, and physical dimensions. It is best to have these in the Gerber format as well as PDF files.
It is vital that you have a detailed BOM for at a minimum the electronic components. An overall BOM is also important, but it is much easier to reconstruct a mechanical BOM if necessary. Electronic components on the PCB are often indistinguishable. A BOM should have a description of the functional characteristics of the part (e.g. Capacitor, 0.1 uf X7R 10% ceramic 16V 0603), as well as specific approved vendors and their part numbers, and a circuit designator reference that matches the schematic (e.g C3, R5).
While not as critical, it is good to have copies of supplier data sheets for critical components defining the characteristics.
The Hex Code is the software that actually gets programmed into the microprocessor. If you have this file you can duplicate your product, but without the source code it will be very difficult to make changes.
The Source Code is the human-readable version of the code. If you hire an outside programmer it is critical that part of your contract is that you get a copy of the source code. Without the source code it is very difficult to make changes in the future, or use the software as a basis for other products in your line. In addition, the source code should be well commented so other programmers can understand the function and intent. It is a good idea to ask for source samples of other code the programmer has written to make sure it is adequately commented.
This document explains how the hex code should be programmed into the chip. Often there are special bit settings or serialization that needs to be configured that may not be specified in the source code. You need to know what these are.