If you are an Embedded hardware engineer or Hardware Design Manager or a company who wants to build an embedded hardware product, it is very important for you to understand how the Embedded Hardware Development Process looks like. What all steps are involved in the Embedded Hardware Development.
Why it is important for Engineers?
Understanding the hardware development process is important for engineers because it allows them to:
- Design better products. By understanding the capabilities and limitations of the hardware development process, engineers can design products that are more efficient, reliable, and user-friendly.
- Make better decisions about trade-offs. When designing a product, there are often trade-offs to be made between different factors. Understanding the hardware development process can help engineers to make informed decisions about these trade-offs.
- Communicate more effectively with other engineers and stakeholders. When working on a hardware development project, it is important for engineers to be able to communicate effectively with other engineers, as well as with other stakeholders such as product managers and marketing teams. Understanding the hardware development process can help engineers to communicate their ideas clearly and concisely and at times negotiate timelines and be more upfront on the realistic view of the delivery.
In addition to these general benefits, understanding the hardware development process can also be beneficial for engineers in specific ways.
For example, software engineers who understand the hardware development process can design software that is more efficient and that takes advantage of the hardware’s capabilities.
Similarly, hardware engineers who understand the software development process can design hardware that is easier to integrate with software.
Why it is important for Managers?
Here are some specific examples of how understanding the hardware development process can help managers:
- Estimate project timelines and costs more accurately: Managers who understand the different stages of the hardware development process can better estimate how long each stage will take and how much it will cost. This can help them to set realistic expectations for stakeholders and to ensure that projects stay within budget.
- Identify and manage risks more effectively: By understanding the different risks associated with each stage of the hardware development process, managers can develop mitigation strategies to reduce the impact of these risks. This can help to protect the project from unexpected delays or cost overruns.
- Make better decisions about trade-offs: Managers often have to make trade-offs between different factors, such as cost, performance, and time to market. Understanding the hardware development process can help them to make more informed decisions about these trade-offs.
- Communicate more effectively with engineers: Managers who understand the hardware development process can better communicate with engineers about their expectations and priorities. This can help to ensure that engineers are working on the right things and that the project is on track.
Overall, understanding the hardware development process is essential for managers who want to be successful in developing and delivering innovative hardware products.
I am working as a embedded systems design consultant to various companies and help them build embedded hardware products. This involves custom hardware development and/or custom firmware development depending on the scope of work. And, the steps mentioned below are exactly what I am following in the process.
So, don’t think it’s just a theoretical knowledge but, are the steps in practice.

In this blog, I will focus on the embedded hardware development, may be I will share steps involved in firmware development in another blog.
Subscribe to my blog
Steps involved in Embedded Hardware Development
(each stage involves multiple reviews internally with in the team, this may include engineers from customers team as well)
- Technical Specification: first thing first, the technical requirement specification is very important. We should have a clear document which states what is required to be developed in the hardware. This typically includes a block diagram to give a bird eye view and details about all the features mentioned one by one. Read more details in this detailed blog how to write a good technical specification document of an embedded product.
- Architecture of the hardware: This is where a hardware engineer & the team defines/decides how to divide the whole hardware into different blocks and how these different hardware blocks will be connected to each other.
- Component Selection: In order to move forward, hardware engineer need to find out components for each hardware sub block. For example, if a USB to UART interface is required in order to connect the device to the PC, hardware engineer need to figure out which USB to UART IC will be used based on technical spec, budget, availability, etc. Similarly if any sensor is involved, hardware engineer needs to find which sensor IC or module to be used. If any wireless connectivity is required, hardware engineer again needs to decide on which module or wireless SoC to be used. Read this article for detailed understanding on how to select electronic components for your embedded product.
- Electronic Circuit Design: Once the main architecture design is ready and major components are selected, hardware engineers needs to design the circuit around each chip for each block. For example, we talked about USB to UART interface, which chip to be used but then what all other components(passives) are required to complete the circuit. Similarly engineers need to design circuit for all other functional blocks in the hardware. There is a misconception that schematic capture is circuit design, it is much complex step.
- Schematic Capture: Once circuit design is completed, Schematic stage comes where engineer design the whole circuit using an EDA tool like Altium Designer, Orcad, KiCAD, etc. This involves creating schematic symbols, designing the schematic with the tool. Multi-sheet schematics are preferred in order have a good readability. One should also add more details in each section which helps any reader to gain basic or important points about the circuit. For example: Typical current consumption of the IC, alternate parts, Label each section on a schematic sheet.
- BOM Cost Analysis: At this stage, hardware engineer has completed the schematic and now knows which all components are used in the hardware, so bill of material cost is calculated to review if the cost of the hardware is as per expectation or any modifications are required to adjust the BOM cost. This is an important step before building hardware design further. Many a times availability issues crop us during this exercise and helps engineer to take a decision to use alternate part.
- Compliance consideration: EMI EMC, Environmental considerations are reviewed in this stage and if any improvements required in the schematic, are done accordingly.
- Test Procedure: At this stage, engineering team defines what all tests need to be carried out to validate the hardware in the validation stage / production sage and what all instruments will be required and how the whole testing will look like. This should be done before designing the PCB so that if any extra test points or connectors are required, can be made available. Many a times at the stage engineers while discussion come to a conclusion to change the position of certain connectors so that automatic Jigs can be used efficiently without wasting much time in loading / unloading of the PCB.
- PCB Design: At this stage hardware engineer designs the PCB which includes PCB footprint creation, components placement, creating the DRC and routing the PCB.
- 3D Model / Mechanical Review: After PCB design is complete, the 3D model is generated and a review is done from mechanical fitment point of view. This stage allows the team to check if hardware fits well in the enclosure. If accessibility is there for assembly, testing, repair and will user be getting good access to different interface. This might influence PCB design changes many a times.
- Generate Manufacturing Files: Once the mechanical review is done and design gets approved. Manufacturing files are generate to be sent to vendors for PCB manufacturing nd PCB component assembly. The main files which are generated are the following:
- Gerber Files (PCB layers)
- Drill Files (Drill information)
- Pick and Place File
- Bill Of Material (Components Part number, Designators, quantity)
- Assembly Drawing
- PCB stack-up details
- Any PCB Fab instructions, if required
- Any PCB assembly instructions, if required
- Send Files to Vendor for PCB, PCBA: Once manufacturing files are ready, these are send to the vendor for Prototype version 1 manufacturing. This stage generally take 3-4 weeks of time. During this time, team will setup the hardware testing jig (manual or automatic), take support from firmware team to develop the basic test firmware which will be used for the testing of the hardware prototype.
- Board Bring Up/Testing/Debug: Once you get the PCB prototype version 1 from the vendor, you need to visually inspect it and check if everything is done as requested and then start testing the hardware block by block. Generally, Proto Version 1 boards are tested by powering one block at a time as there are chances some design issues are there, if we power full board, we may end up loosing the whole hardware. That’s why block wise power up of the circuit and testing is preferred. If any issues are found during testing, those are debugged and engineer will try to fix the issue with some workarounds like jumpers, using external components or hardware, etc. This stage may take several weeks like 3-4 weeks based on the complexity of the hardware for testing. This will ensure prototype version 1 works well and issues do not go to next prototype version.
- Review Points from Prototype Version 1: One the testing is completed, engineers know what all issue are there in the board, those are noted down and discussed with the team to take a decision which all need to fixed and which are not that important. Issues like extra label on board, repositioning of any connector for ease of testing etc. are also noted not just the design issue. The whole idea of this stage is to find all points(minor/major) which needs to be improved which will reduce the effort in testing, assembly, repair, etc. In many cases this stage also involves compliance testing in-house or in an external Lab.
- Delta Design changes for Prototype Version 2: After the review of prototype version 1 testing is done, design changes are implemented considering all the review points. This stage aims to make sure Prototype version 2 should not have any issue and should be good enough to go for initial 100-500 units pilot lot production which can be used for field trials. Changes may involved in Component changes, changes in Schematic, PCB. Design cycle repeats for prototype version 2 from point 5 to 13.
- Ready for Pilot: In 99% of the cases two iterations are good enough to produce a hardware which is ready to pilot lot production. But, if design is still not ready due to technical issues, it may need further iterations. Cycle repeats from 5 to 11 for each iteration.
Above details gives a good overview of what all happens in a typical embedded hardware development cycle, a lot more goes in the process which is not covered here for the sake of simplifying it and making it easy for everyone to understand at high level.
I hope you have understood the steps involved in hardware development of a product.
If you need help in embedded product development, I can help you with my design services.
If you have any feedback, you can share in the comments section or you can also contact me directly.
Read more interesting articles on Embedded Systems Design.
Great and useful blog really helpful.
Embedded Engineering Services for Product Development
Dear Pallav, very interesting article and a good starting point for embedded engineers. Just one point – normally I start with a Functional Requirement document that includes – functionalities as required by customer, device operating conditions, any certifications andEMI/EMC requirements. This way, right from the beginning, the designer takes care of everything that the device will face.