By Greg Austic, Julian Stirling, Jenny Molloy
This is the sixth post of the series of the Open Hardware Distribution and Documentation Working Group (which we’re shortening to “DistDoc”). The group aims to produce a proof of concept for distributed open science hardware (OScH) manufacturing, exploring key aspects like quality, documentation, business models and more using as a starting point a paradigmatic case study. We hope the experience motivates others to discuss and implement new strategies for OScH expansion.
Producing scientific hardware is complex. Assembly can involve more steps than manufacturing other types of tools, quality checks and tolerances on parts can be demanding, and there are often unusual calibration or validation procedures according to the specific type of equipment.
Producing open source hardware is complex because to do it well (say, as per the GOSH manifesto), you need to document it in a way that others can build it, and attempt to make your BOM [1] as accessible in as many locations as possible.
Distributed manufacturing means manufacturing a single product in many locations: adopting this model for a high quality, saleable product is complex. Several disparate groups in different environments, potentially using different tools and with access to different supply chains all need to follow specific manufacturing procedures accurately to create a consistent product.
We are attempting to find the right way to combine these complex things — producing open source, scientific hardware using a distributed manufacturing structure. In this article we’ll focus on the documentation and quality assurance parts of the framework we defined to start working, as discussed in previous posts [2].
Documentation: Gitbuilding
There are already so many ways to document hardware, you might think this is already solved. We have tools like Google Docs, GitLab, or even just a pen and paper. Why — you might ask — did we feel these solutions weren’t sufficient?
The biggest problem is not writing documentation, but keeping that documentation up to date. If you choose to change one screw from being a cap head screw to a button head screw, how many places do you have to update it — and how many hours are lost if you don’t update it everywhere the same? You will probably need to change it: in the assembly instructions where the screw is used, in the bill of materials spreadsheet, maybe in another page which lists the parts used in a particular section. That doesn’t sound too hard.
But over time things get missed and the instruction quality degrades. This is particularly true for complicated projects where there are multiple variants of the same design, or where different manufacturers locally source slightly different parts based on their local supply chain.
With GitBuilding [3] we are creating a format where the data about part usage is embedded right into the text where the part is used. This information is then processed to make lists of parts in the documentation, or even bill of materials spreadsheets. We just released a feature so that you can write a procedure once, and use it for multiple variations of a design. This will allow all versions to stay in sync.
Quality Assurance and Quality Control (QA/QC): SurveyStack.io
At its core, quality assurance means measuring stuff, writing it down and acting on any discrepancies from the expected measurement to continuously maintain — if not improve — all aspects of manufactured product quality. It is time consuming and more resource intensive than you might imagine. Prusa, the Czech 3D printer maker, spends 25% of its total labor just on measuring parts coming into its process (length, presence of burrs, strength, etc.) and removing parts which don’t meet their required specifications.
Once more, quality management systems are commonplace in many industries; why can’t we just use those existing systems, or Google spreadsheets or even good old pen and paper for distributed manufacturing of scientific hardware too? Several reasons:
- QA, QC and documentation are part of the same process — so instructions, data inputs and connections to hardware should flow one from the other rather than across many services with independent points of failure. Going back to our previous example, if updating your cap head screw to a button head screw causes issues with different versions of documentation that need aligning, that change also needs to be rolled out across any QC procedures such as tolerance testing, calibration procedures and checks. For larger changes you may also need to update staff training, which is also more complicated across many sites.
- There are many (many) dependencies along the way which need to be handled — dependency ‘logic’ is required. What happens when a part fails, where do I put it? What if a unit passes two tests, but only just barely, should it get reworked? What if I want a colleague to review the results of my last months worth of QA results to check for errors? In a single manufacturing location, this challenge is often best handled by pen and paper data sheets and check boxes, clear work areas, and well organized file cabinets, and their digital counterparts. Across many distributed locations, you need a different system.
- Flexible + integrated reporting and monitoring matter a lot more when you have manufacturing partners whose business suffers when you ship failed / low quality products. So — transparency is doubly important for a distributed manufacturing strategy. Moreover, integrated reporting allows you to integrate learning across sites. Are repeated failures a result of the overall design, of the intended assembly process or due to a local problem? In some ways distributed manufacturing can be advantageous: it should ultimately select for designs and processes that are more robust to changes in environment and personnel.
Surveystack.io [4] is open source online survey software that captures data throughout manufacturing processes, enabling fine-grained reporting and broad integration. This allows distributed manufacturers to achieve a single, simple, cohesive process from the manufacturing perspective AND use fully open source software rather than a range of closed-source alternatives.
A simple, effective manufacturing experience
Our group, together with the developers of Gitbuilding and SurveyStack, aims to combine these two tools so we can soon have the features needed to cover documentation and QA/QC needs for a wide range of potential manufacturing projects.
These features include:
- Organizational management (admin, members, logins, etc.)
- Flexible survey and instructions building w/: 1) if/then + more expansive dependency logic, 2) Mobile + offline friendly
- BOM management and simplified BOM references
- Version control (BOM, surveys, and instructions)
- Well designed UIs for instructions, data input
- Fully open source software + built with integrations to other services in mind
Thinking of possible scenarios, projects with large/complex BOMs, many versions across time/space, and relatively simple QA/QC needs can use Gitbuilding alone. In the medium term, we are interested in ways to transfer data (such as simple checkboxes or single numbers) from Gitbuilding into SurveyStack for storage. This would allow projects focused on Gitbuilding to add a little bit of QA/QC easily, while maintaining a cohesive (Gitbuilding-only) user experience.
On the other hand, projects with detailed and/or complex QA/QC needs and relatively simple BOMs and versions can use SurveyStack alone. In the medium term we are interested in using Gitbuilding’s flavor of markdown in SurveyStack to enable at least some intelligent BOM management within SurveyStack’s current simple markdown framework. This would allow projects focused on SurveyStack to use some of the best features of Gitbuilding, while maintaining a single-service user experience.
These same ideas can also be applied to other areas of manufacturing. As an example, Beneficial Bio is a company manufacturing biological tools in Cameroon and the UK that will trial SurveyStack for QA/QC in biomanufacturing. We are also exploring the parallels between distributed hardware manufacturing process and distributed biomanufacturing, where the documentation needs and BOM can map to standard operating procedures and standardised DNA parts lists.
Keep monitoring here for more updates!
Notes:
[1] Bill of materials [2] https://medium.com/@journalopenhw [3] GitBuilding is developed by Julian Stirling and other members of the Bath Open Instrumentation Group. [4] Surveystack.io is a project of Our Sci LLC, from Ann Arbor MI, learn more here.