Outsource design
Outsourcing of the design of an electronics board is not an easy task. The following is an attempt to write down what we be believe are the steps required to arrive at a good design with the right amount of documentation. Note that this workflow is specific to CERN's CO-BE-HT section.
Process stages
- Requirements Specification - CERN
- Write a short list of requirements (on the ohwr.org wiki page created).
- This answers the question "What do we need?" It does not enter
at all into the details of how we intend to do it. It is a user
view.
- The end product for this phase would be a "Functional Specification" document. However, for most projects a bullet list of items is good enough.
- Review requirements with the users.
- Technical Specification
- Here the architecture and globally what components will be used are decided.
- The end product for this phase would be a "Technical Specification" document. However, for most projects a clear block diagram and possibly some slides are good enough.
- Review the technical specification first within the company (cross check), then with the users and CERN.
- Schematics Design
- Use Altium
-
Use only CERN's component libraries. If components are
missing, request them. Do not make symbols yourself.
- This guarantees conformity to certain IPC standards, that all symbols have a common look and feel, that padstacks are correct etc.
- Use checklist from Schematics Design Review.
-
Review the schematics first within the company (cross check),
then with the users and CERN.
- Improve the Schematics Design Review checklist if possible.
- PCB Layout
- Use Altium
- Use only CERN's component libraries (all symbols will have their padstack already)
- Component placement
- Review component placement, first within the company, then with the users and CERN.
- Layout
- Review PCB layout, first within the company (cross check), then with the users and CERN.
- Production File Generation - CERN
- CERN's design office will review the design and clean up any issues detected.
- All production files will be stored in EDMS in a standardized way.
- Documentation
- All documentation should be stored on the project page on ohwr.org.
- Review documentation first within the company (cross check), then with the users and CERN.
- Prototype hardware
- Three assembled prototype modules should be delivered.
- If the Production Test System is ready, these modules should be tested before delivery.
- Depending on who is doing the final prototyping and acceptance, CERN or the company should debug the card.
- Gateware and firmware
- Depending on who is responsible for the final product, CERN or the company should write the gateware and firmware.
Tight Follow-up
The lightweight method described above is likely only possible when a tight contact is kept between the responsible for the project and the company developing the test system.
-
A weekly phone call is seen as the minimum required.
- We believe that as follow-up (phone calls, intermediate reviews) needs about 10% of the time that the company spends to develop the design. E.g., half a day follow up for each week of work by the company.
Continuous improvement
After every stage of the process a meeting should be held to discuss and analyze possibilities for improvement.
Documentation required on delivery
Based on the technical specification that we use for Open Hardware cards, we expect some documents with a delivery.
- A lightweight document describing the design.
- It could be written in an informal way, like how you would directly explain a design to a new colleague, while having a coffee.
See also
-
Outsourcing of the development of Production Test
Systems
- Can be started when the schematics are known.
- Outsourcing of production
Erik van der Bij - 29 June 2016