Electronics Projects: From Concept to Product

This post we will cover the six major project phases involved in taking an idea for a new hardware product and turning that idea into something tangible, something that can be manufactured at scale. These phases are:

• Pre-project research
• Building a concept demonstrator
• Robustification into a deployable proof of concept
• Development of a reproducible prototype
• Finding partners to produce an optimised PCB design
• Manufacture and quality assurance at scale

Software vs. Hardware Projects

With purely software-based projects it’s relatively easy to make small changes and fix bugs. Even huge changes are possible and can be sent into production without much effort—especially in today’s era of Continuous Delivery. For hardware, this is a different story. Only the tiniest of bugs can be fixed; anything more requires starting again and building a new board. This gets expensive and wastes time. That’s why the primary focus of this process is to elicit requirements. The production of a final hardware design can only really take place near the end of the project once our business requirements are locked down.

However, we can’t acquire these requirements unless we have a version of the hardware to demonstrate and trial our solution. For this reason, the process also emphasizes the development of hardware prototypes and concept demonstrators that can be shared with clients from the very beginning of a project. This idea and its importance will be further explored throughout this post as we discuss each of the project phases.

Pre-Project Phase

The Pre-Project phase kicks off once a client has first expressed their vision for the new product and involves researching the current technology available in that space. Essentially, the goal of this phase is to explore potential options for building a solution and determine the steps to carry out to hone in on the right technology choice, or determine if it’s even feasible to build the system the client has in mind. This might involve going through some basic tutorials and tinkering with circuits to get a feel for things and will also help start the conversation with our client to elicit project requirements and options to fulfil them.

Out of this phase, we produce a list of the additional spikes we’ll need to complete to answer the remaining unknowns around the project, allocate time to each of these, and order our first round of parts to start experimenting.

The example below shows a basic application which was built upon a tutorial on AWS IoT. This example allows us to control two outputs remotely via an online console, but more importantly, it points to other questions we need to answer. Questions like: “Is it possible to automate this process?”, “Can this be implemented in other languages?”, and “Can this be implemented for different hardware?” form the basis of our spikes moving forward.

Concept Demonstrator

Now that we’ve begun to build our understanding of the problem and have completed some preliminary exploration we can start to build a concept demonstrator and do some more targeted research based on the set of spikes we highlighted during the Pre-Project phase. As with the previous phase we breadboard up a circuit, but in this case our aim is to solve the client’s simplest use case. This is put together with whatever we have on hand and off the shelf parts we can get a hold of quickly. We also put together an end to end demonstration of the software required for the selected use case based on what we’ve learnt from the spikes.

During this phase we leverage the skills we already have to produce a working solution quickly, rather than attempt to implement the best possible solution. This is because it’s more important to iterate fast and get as much feedback from the client as possible by giving them something with which they can interact. Due to the nature of its construction, it’s not expected at this stage that the hardware will be portable and/or deployable in a realistic physical environment—at this point that’s not the goal.

In the case of the example below, the client’s simplest use case was to actuate two motors remotely, report temperature and humidity data, and keep track of time even if the unit loses power for a short time. This was accomplished using a motor controller, off the shelf sensors, and a real time clock wired up to a Raspberry Pi Zero.

Deployable Proof of Concept

We then develop a deployable proof of concept, which is basically a soldered-up, more robust version of the breadboard circuit from the previous phase. As with the previous phase, this is made up of off-the-shelf parts, this time soldered onto a perf-board or proto hat. Making our proof of concept robust enough to be portable means that we can give one or two of them to the client so that they can start trialling the hardware in a way that’s more representative of the product’s actual environment to provide us with feedback. This also means that we can trial and continue to build out the software as well as settle on a system architecture without having to wait for our final hardware design to be complete.

It is worth noting that while the components selected in these early stages may not end up being those used in the final product, we can use these selections to reduce the extent to which we’ll need to double up on work like creating device drivers. In the example below we selected ICs which support widely used protocols like I²C wherever possible.

Prototype

Based on the feedback from the trial of our deployable proof of concept, we can elect to design a custom PCB for an easier to assemble prototype. The advantage that this provides is that we can now assemble a larger run in-house. If a project only requires 10–20 units this phase may be all that’s ever required. The larger number of units means we can deploy the unit to more test users for a diverse set of feedback and start to gain an understanding of the requirements of maintaining the overall system once more users are active. This extra feedback gets us close to finalising the product’s hardware requirements. You’ll notice that at this stage of our example project we were targeting the Raspberry Pi for development, with the example below showing a Pi Hat we designed. However, this was later changed to an ESP32 to reduce the cost of the product, improve responsivity to user inputs, and for robustification of WiFi connectivity. This highlights another key strength of this project lifecycle in that we were able to build the rest of our system architecture, such as back-end web services, user management, Android application, interfaces with AWS frameworks and deployment, all before we had a final hardware design.

Professional PCB Design

At this point we need to partner with an external electrical engineering firm to design a printed circuit board (PCB) which can be produced at scale. This is to reduce costs through economies of scale, handle any accreditation required for our product, and ensure that the design takes the manufacturing process into consideration.

During this phase the benefit of all the effort we’ve put into requirement elicitation becomes apparent. The exposure which we now have to the problem makes it much easier to liaise between our client and this firm while communicating the requirements we need their hardware design to meet. Being able to demonstrate how our prototype works and interacts with the rest of the overall software solution also helps expedite this process.

Lastly, because we’ve been able to develop this software solution in parallel with the hardware, we can quickly evaluate the new hardware that our partner designs and provide them with feedback. Any changes that need to be made to component drivers will be minor as we were careful with our initial selections in the proof of concept stages.

The PCB shown below is based on the ESP32 and its interesting shape has been designed to fit within a pre-existing housing. It’s likely that a PCB design will go through a few iterations as we figure out the last few requirements for manufacturing our new product, but the changes to our code will in most cases, including this one, be minor.

Manufacture

The final steps before finalising a project for handover are the evaluation of the board developed by our external partner through a trial of 10–20 units, and the implementation of a production line test.

Again, we can leverage the software we have developed throughout the project to make the creation of this test relatively straight forward. As we’ve been able to develop and trial our software in parallel with the hardware development, we now have an almost complete implementation. This implementation includes drivers for interacting with on-board ICs, outputs like LEDs, and inputs from buttons. This means that we can now carry out a bed of nails test of all the components by triggering an on-board test, which simply calls functions that we’ve already written and compares the outcome to a set of expected results.

The example below shows the results of such a test. In this test a set of on board I²C components are contacted by writing commands to them and reading back results utilising the device drivers previously developed. Being able to quickly implement tests like these gives us a reliable and repeatable approach to quality assurance which can be carried out with little disruption to manufacturing.

By this point, we have a full understanding of the requirements of the product itself, so the trial is to give us confidence that not only does the product solve the given problem, it can be produced and tested quickly, and maintained at scale.

Breaking our hardware projects into these six phases, pre-project, concept demonstration, deployable proof of concept, prototype, professional PCB design and manufacture, provides some key advantages. Progression through each of these stages increases the cost of failure (and starting again). Because we have a heavy focus on making sure our requirements have been validated from the get-go, we avoid spending more in the later stages by limiting the impact of the adjustments needed to earlier, cheaper concept demonstrators. And, because we haven’t over-invested in early prototypes, we’re able to start again and iterate as fast as possible on feedback.