It can be very frustrating when looking around the internet for specific answers regarding the hardware development of an IoT device, what it would take to get it to the production lines? Many devices do not make it to the production lines because they tend to move too fast or too slow and not follow a road map.
Follow along if you are starting or about to begin your journey into the embedded development of an IoT device. Remember, just because you are a beginner does not mean you cannot do it. If you have the will power to learn and accept feedback, you will make it. Just be patient as it is a long process and needs special attention to details.
Soon as you have an idea, begin following the road map. The sooner you follow the road map, the faster you will understand the process and the time it takes to bring your device to life. In general, these are the phases in a new embedded hardware device.
Road Map to Production Phases
The requirements phase is one of the most important phase of the development process and needs to have a lot of attention, it really does deserve it. It will save you so much time down the road, so do not take the short cut.
In simple terms, you want to be able to describe and answer questions about the product’s engineering requirements to initiate the project. Requirements are specific bullet points that outline the minimum approach to building the product. Very detailed and well written How to Write an Engineering Requirements Document article would help you get started. Here are some simple questions to ask and try to answer about the product:
- What is the ultimate goal and purpose of the device?
- List the constraints that are needed to be followed to ensure successful release
- What are the risks?
- Any timelines/deadlines and expectations?
- How do we handle the suppliers and manufacturers?
- What are our budget for the device’s R&D and prototyping?
- Any final cost goal of the device?
- What are (if any) government requirements that are needed to certify the device?
- Any drafts of how the final device should look like and function as?
- and much much more…
The more questions you answer now, the better setup you are on the following stages.
This is my favorite stage. It is where we get to be as creative as possible to solve the questions asked earlier, in the requirements section. Begin by designing by paper, my favorite are drawing pads, to free draw the external of the device and how it could look like. Then start to think about the inputs needed, such as sensors, and the outputs, such as switches. It is time to think about how you want to approach the firmware. Is a RTOS needed? What is the complexity and how to navigate throughout the process of writing the firmware?
For me, personally, I like visualization. So a sequential graph is my absolute favorite to begin the design of the firmware. You can make your own be using mermaid MD tool for visualizing diagrams and much more using Markdown syntax.
Next, you want a simple list of materials that are needed to go with the device. Does not need to specify the details but for example: if you needed to build a device that records the changes in current in a wire. You would know what general components you would need, and can easily list them. If you do not know which component you need, take a step backward and research the components needed (if available) to satisfy your device needs.
You want to be able to generate preliminary designs for hardware and firmware (drafted by hand) and documentations outlining any scientific findings or white papers that are used to support your assumptions.
Take what you have drafted on paper in the concept phase and transfer it to version 1 designs. That being the PCB layouts, schematics and the 3-D drafting of the enclosure (if one is custom made). Remember you do not have to have a perfect design on the first try, this is an iterative process and more than likely will be back here after testing and prototyping.
Use a simulation software to help understand the static and dynamic forces on the plastic enclosure design. When designing the enclosure, keep in mind DFM (Design for Maneuverability). At first you would need to design two separate designs, one for 3-D printing testing purposes and one for a plastic mold. As a good place to start, read up on the DFM for IM (injection mold).
If it is your first time designing and learning to make embedded systems, I would start with KiCad. It’s a very useful software that is open-source and has the ability to produce complex designs. After completing your layout design and BOM, create a 3-D output file and test against your enclosure to ensure fitment.
Start writing codes of firmware, test against a development board of the chip you will be using. Version 1 does not have to be perfect, but needs to be functional!
Send those final design files from the previous phase over to a 3-D printing facility and board house to have them physically to conduct some prototype testing. The testing here is light and needs to ensure that at least the functionality is in check. Generate a testing criterion in this phase to be successful in the next stages. It could be a simple Excel file that lists a test you conducted and whether the device passed or failed. The requirements document you made earlier would be very helpful here to make sure you are hitting the necessary features.
It is okay if version 1 is not the best, make a version 2 after you revisit the design stage and move on to the next stage, Testing.
Use the Excel document and add further testing cases to ensure each feature is implemented and meets the minimum requirements. Reiterate until all tests have passed. While the device is going under testing, work on brainstorming testing that needs to go on to the production floors and what that might look like. Does not have to be a perfect document, but something to get you thinking about what the testing would look like in production to ensure quality is kept high.
Produce reports of testing in each version to keep track of your changes in case a root issue comes up when a change happens. It also helps to ensure that your product is as safe and reliable as possible when you are ready to sell.
Government Testing and Certification
If the device falls under any regulated areas, then most likely the device would need to undergo official testing to receive a certificate of compliance, such as FCC in the US.
Read as much as you can on the requirements and look to partner with a testing facility to pre-test your device and ensure it is ready to be officially tested, as failed tests can be costly very quickly and many budgets forget to include this stage. Read books and articles about passing the test on the first for the regulation you are working with to make sure you cover all the areas. Spend a lot of time here so you won’t lost the budget.
Pre-Production Model Testing
Prior to going to mass production, you need one more testing phase. To test the final end device that would reach a end user. To get the most out of this stage, you want to get as close as possible to a final device and possibly even manufacture 100 of them to be tested with friends and family or investors. As you are going thorough a more scaled process, you would figure out an item you might have overlooked over the previous stages.
This model would also need to be used for the Government testing to ensure you are as close to the final product as possible and no changes are going to occur. As once you make a change to a certified device, more than likely you would need to have it retested.
In this stage, you should have a list of your close manufacturing partners and suppliers and they are ready to go with timelines of when you give them the go ahead for mass production.
Hurrah! You made it to the production stage. Take a moment to pat yourself on the back. This is one of the hardest stages to get to. In this stage you will sit back and relax and watch as your product is being produced. Begin the inventory storage and business plan (which you started of course during the requirements stage).
After users receive the devices, they need to know the device would last them as advertised. Have a plan in store for supporting the device and its users which unforeseen issues occur. What is the process behind returned devices and how do you make sure that this does not occur in a future release? Keeping track of support tickets and issues that are being called about the most to catch them before they break free and destroy the image of the device. What is the warranty process and how long do you plan on guaranteeing a device’s life time?
Hope this post was helpful and of course if you have any questions, please feel free to reach out directly or by commenting below. Will get back to you as soon as possible. As we are starting out, we wish to hear more feedback whether constructive or destructive… we want to learn regardless.