Electrical Engineering Stack Exchange is a question and answer site for electronics and electrical engineering professionals, students, and enthusiasts. It only takes a minute to sign up.
Sign up to join this community
I'm getting ready to hire an electrical engineer for a small contract job - creating a prototype. What I'd like to know is, what should I have him deliver to me when the project is complete?
I imagine schematics, the prototype, parts list would be standard, but what am I missing? Should I ask for an auto-cad file - not sure what this is yet... Are there other things that I would need in the future for a different engineer to take over the project?
Simply, what should I be asking for?
Design engineers won't like the idea, but as a design engineer my output for a project is a pile of paper. In a strict sense the working prototype isn't even required, though it will certainly put the client's mind at ease. :-)
We'll see that you need a lot of documents, and design engineers are not motivated to the task; read: they tend to make a poor job of it. They're better at other things. Therefore some companies have a documentalist in a team, to follow up the documentation phase.
You need documents for every phase in the product's lifetime:
- Production
- Maintenance
- Repair
- Disposal
Production
This is the most extensive, and will get the most focus (and unfortunately it often stops there).
- Schematics
- PCB layout (Gerber files, including drill)
- Bill of materials
- Datasheets for all of the BOM(!)
- Mechanical drawings
- Software sources (incl. project file)
- Software object files
- Test jig design and operation instructions (this can include all the above files!)
- ICP (In-Circuit Programming) procedure
Maintenance
- Document(s) describing the procedure and tools for the product's maintenance, and how to replace consumables
Repair
- Document(s) describing how the product has to be taken apart for replacing defective parts. Specifics about how to replace parts which may fail during the product's lifetime (based on FMEA. You did an FMEA, didn't you?)
Disposal
- Document describing how the product has to be disposed of at it's end of life, with details about hazardous products and components.
Whenever possible documents should have a version number and/or issue date (you don't always have control over this, especially with external documents, though most datasheets will at least have either a version number or publishing date). You want all documents both in native format and in a standard electronic, printable format, like PDF. Specify how the electronic files have to be delivered: cloud (not a favorite of mine, confidentiality-wise), CD, DVD,...
As a note I want to say that especially in small projects even project management isn't often interested in anything else than schematics and PCB layout. Every one of these projects, without exception, runs into trouble later on.
Assuming the engineer will be creating a printed circuit board (PCB), they will be using some sort of schematic capture and PCB layout program. You want to get a copy of his design files (not just the final output, such as a PDF of the schematic), so that they can be turned over to another engineer in the future if needed. Otherwise the second engineer would have to recreate the design files from the drawings.
For example, I use Eagle PCB, so the relevant files would be the schematic (.sch) and layout (.brd) files, along with any custom parts that I have added to a library (.lbr files). Also any unique design rule checks (.dru) and tooling files (.cam).
Although the Gerber files, which are sent to a board house to make the PCB, can be recreated from the design files, it would be a good idea to get a copy of those also.
There is no standard for the part-list (a.k.a a Bill of Materials, or BOM), but they are usually created using a spreadsheet such as Excel (.xls file). Make sure the engineer provides a source for each part, such as a Digi-Key part number.
If a prototype case is being made, for example with SolidWorks or other CAD software then you will want to get the relevant files for that as well.
To add to the other descriptions, If your engineer uses Altium Designer, the file types are as follows:
*.PcbDoc - PCB File
*.SchDoc - Schematic File
*.PrjPcb - Logical project Grouping file. Not absolutely necessary, but nice to have.
*.PcbLib, *.SchLib, *.IntLib - PCB Library, Schematic library, and a baked-together library with both pcb and schematic primitives (note: if you get either a *.PcbLib AND *.SchLib, or just an *.IntLib, you're fine. they can be converted back and forth without issue).
All the DFM and DRC rules are packaged into the *.PcbDoc file, which is nice.
Getting the design files from your engineer is critical. I've recently been working on a project where the electrical design was farmed out, and no one knew what files they needed to get from the design house. Fast-forward a few years, and the design-house went out of business. and I'm stuck having to recreate the boards from the gerbers.
Maintenance is a nightmare without the proper files.
Here is what I have typically delivered --
Initial Prototypes
Two functional prototypes. These boards may contain minor engineering changes but will be sufficient to verify functionality. It is expected that one revision of the design will be required.
Final Report
A design summary report that includes schematics, BOMs and component datasheets. All major design decisions are documented. Recommendations for future improvements are included. When I create the report I structure the BOM so that each line item in the BOM is a hyperlink to an embedded datasheet for the component.
Software Files
All application and library files.
EDA files
All EDA files for the first revision of the design.
Production PCB Files
If required, CAD files and manufacturing drawings to produce PCB panels will be provided.
Cost Estimates
Provide cost estimates for building multiple units.
If they're in your hire, you should expect any designs they made while working for you, notes regarding their designs, any reports made during the process (incluing the final one), and pretty much anything else that related to the contract.
The deliverables should be clearly laid out in the contract, or at least a very good attempt should be made to do so. If both parties don't agree, rewrite the contract until they do, or move on. Avoid vague terms that mean whatever anybody wants them to, like "documentation". Include milestones, like a review and sign-off on a real specification document and test plan. The bigger and more involved, the more important to get the list of deliverables right. If you're nearing the end of a project, and you or your client aren't very sure about what will be handed over, your communication with your client could use some improvement. Good engineering + good commmunication = satisfied customer.
Ask about test and troubleshooting too: eg. TP3 should be at 3.3V, TP4 at 5V, TP5 at 1Mhz clock. List of devices expected on JTAG scan chains. Software binaries and source code for any firmware.