Open Hardware Production

For sometime now I have been submerging myself into hardware and in particular emergent OpenSource Hardware (OSH) projects. That was one of the reasons for kicking of the Open Hardware Hackers group in London recently. I am finding it fascinating and it is taking me back to my system engineering roots but unlike OpenSource software, OSH still has hurdles and obstacles which make it more challenging. As with all good OpenSource movements these challenges become scratches that one must itch, OpenSource is a process of creating solutions, removing barriers and more importantly enabling others to tread the cowpaths that one co-creates.

So what I want to share today is the challenges of OpenSource Hardware Production (OSHP) and the work I have been researching in order to overcome some of these obstacles I (and many others) have experienced.

In order to understand the problems of OSH I will compare it to OpenSource Software (OSS) a more familiar OpenSource model. The biggest main difference is that OSH requires ‘Hardware’ or more importantly components and connectivity. Software has no such requirements. OpenSource Software production is merely the digits these can be produced and transported and duplicated at almost zero cost. Hardware on the other hand has very real physical costs :- components, PCBs, tools, assembly, transportation etc..

It is therefore no surprise to find that hot areas in OSH are ones in which these costs and complexities are reduced, a good example is the burgeoning Arduino OpenSource Hardware community. The way that Arduino helps mitigate some of the challenges is down to the nature of the device and its implementation.

First Arduino is a microcontroller based device, this is like a microprocessor (CPU) with built in peripheral pins to make connecting to simple actuators, indicators and measurement/detection devices straightforward using just a breadboard and some wires. Secondly it relies heavily on a familiar concept ‘software’ to make it useful. Although this software is much lower level and hardware device oriented it can benefit from OpenSource software models that we are already familiar with. Production and distribution are therefore relatively simple using the familiar OSS model, albeit with the proviso that you need to have an Arduino dongle. In fact in the OSS world we also need a dongle that dongle is called a PC, which is now so familiar and common place that we don’t actually see it as such. For the Arduino community you actually need 2 dongles a PC and an Arduino, in fact you might also need a few other bits to make it interesting such as a Breadboard and some components, a market for Arduino kits has thus emerged around the community to satisfy the need. Even the Arduino itself is available in many different formats from different supplies in addition to the ‘official’ founder organisation who started Arduino.

In trying to build OSH projects one comes across common issues with supply, production and assembly because of the way in which the embeded/device industry has grown up. This industry is based around around the head of the production curve, focused on producing popular items in extremely large quantities. For those playing in the tail of the production curve manufacture costs rise steeply as they lean on prototype scales rather than mass production. Having priced a number of projects we are working on I would commonly find that producing 100 unit vs a couple of units results in significant lower cost per unit. These costs are not just the raw components but the connectivity (PCB) and assembly. In some cases this can be alleviated by producing ones own PCBs and assembling at home. There are however some pitfalls to this approach. The industry has rapidly moved to Surface Mount production over the last decade and many components are only available in this format. Home surface mount PCB production and assembly is not for the faint hearted and requires special tools and processes. Thus home production at this time (apart from certain categories of through hole production) is out of reach for many.

So how can we overcome such obstacles for production? well lets take a leaf out of the Arduino book and take it a little further, abstract it and expand it’s community range. Even though we love our Arduinos we can’t do everything we would like to do project wise. It was initially designed as an educational device for teaching about embedded microcontrollers and as such took on certain constraints in its initial design. For example it is designed for experiment and prototype rather than production or deliver, secondly it is confined to a narrow 8 bit microcontroller range from a single vendor (Atmels ATmega subset). Often I needed to use 16 or 32 bit controllers from the Arm family provided by many competitive vendors. Thirdly Arduino’s expansion and customisation routes using shields (daughter boards) does not go far enough in solving the production and assembly challenges outlined above. It became clear to me whilst trying to get around these limitations the challenges could be resolved using a more abstract and general design by taking a birds eye view of the processes. below are some guideline requirements to solve some of the challenges experienced and grease the production wheels for OpenSource Hardware Production:

  1. Software as a major component for projects which means microcontroller based. However this should not be confined to a single vendor or family.
  2. Standards based on OpenSource implementations and documentation using low cost components.
  3. Modularity, like the linux kernel, build modules that conform to the standard and that solve common requirements, let the creative process snap together modules to resolve bigger design challenges. Also leverage the cost benefits of volume production for popular modules.

Modularity is key to the abstraction and there are several important features which will amplify its usefulness:

  1. Module composition will be constrained to certain physical dimensions and connectivity. These constraints are designed to optimise Both PCB/component construction costs and macro-assembly into standard physical compartments.
  2. Module functionality should be designed such that the largest possible audience for their usage should be considered. This should mean design scratches the biggest itches at the lowest production cost where possible.
  3. Avoid overlapping or duplicating of functionality, each module should be designed to co-exists with one or more other modules in order to solve problems via composition.

These requirements lead me to a number of projects moving forward, the first an most obvious would be that of an open hardware device bus. This will allow modules (small boards) to be assembled at low cost which slot into a simple hardware bus managed by a microcontroller. The bus itself is very simple and requires little additional component support in order to make building peripherals a snap, modules and the bus itself as well as controller implementations will be opensourced to provide reference standards.

Please let me know your thoughts, does this make sense, would you like to get involved, would you like more info, should we setup a wiki or user group to get it rolling? let me know.

About this entry