Hardware and Embedded Software Development: The Project Management Side

This article was originally published by Alvaro Rios, Head of Engineering - Medical Devices. This is an updated version.

Join me, as we picture a typical July day in Montevideo, Uruguay, where the weather is often grey and windy. Just about the perfect day for a coffee and bizcochitos – it's common knowledge among my fellow colleagues that I've replaced most of my blood for coffee long ago.

Given the ideal conditions to trigger creative thinking, we started brainstorming and discussing one of our organization's major concerns:

• What do the best processes to manage hardware and embedded software development projects look like?

One of the main things I love about Focus is that my work comprises three awesome areas:

• Embedded software development.
• Electronics design and hardware development.
• Engineering management of a skilled team, focused on the design of medical devices.

I've seen the unique challenges that come with the mix of these three fields.

Embedded software development is still a niche in Uruguay and it requires a different set of skills and processes when compared to those typically used for software development. Moreover, my experience has taught me that hardware development is quite a rough ride when compared to software. Tons of knowledge and experience in a variety of areas are needed just to develop and mass manufacture a small, simple piece of hardware that serves the purpose of little more than Christmas tree lighting – many of you must be acquainted with the classic blinky project.

When it comes to management, combining hardware and embedded software is no easier task. Intuitively, the former has a more waterfallish approach while the latter looks like a candidate to apply agile techniques. For this reason, at some level, it's like herding cats, because this kind of project involves multiple teams working on different components of a product with the inevitable complications that stem from making sure everyone is concentrating their efforts towards the same system integration goal. We try our best to ensure that the hardware and software emerge as a unique product.

After facing some headache-inducing projects, we've had to up our game and streamline our processes to achieve the best quality and delivery of our capabilities. The highlights of this beautiful journey, which is ongoing, are what I want to share with you in the following paragraphs.

Episode III: Revenge of the Change

When it comes to designing electronic circuits, there are several stages that are typically followed. Here's a breakdown of these stages:

• Circuit Design and Simulations: This is where the analysis of the hardware requirements is done, and a set of circuits to achieve the solutions is proposed. During this stage, simulations are done to make sure they'll work properly.
• Schematic Development: Schematics are blueprints for the circuits. They represent the system in an abstract way and act as a common language to help engineers understand the different components and their connections. They also provide a roadmap for the PCB layout.
• PCB Layout: This is where things really start to take shape. As a first step, mechanical considerations must be taken into account to create a floor plan for the components. Then the routing of connections by traces on the PCB is made, following several manufacturing design rules. Also, the PCB layout might aim to optimize performance, minimize noise, and meet size and cost constraints.
• Manufacturing Files Generation: Once the PCB layout is complete, the manufacturing files can be generated. These include the Bill of Materials (BOM), which lists all the components needed to assemble the PCB. In this stage, Gerber, Drills, and Pick and Place files are also created, which contain the information necessary for manufacturing and assembly.
• PCB Testing: The final stage involves testing the PCB to make sure it meets the design specifications and functions correctly. Several tests for electrical performance, signal integrity, and compliance with regulatory standards are done at this stage.

The costs and time required to introduce changes to a hardware project increase as the change is introduced later in the development cycle, even if the impact on the product is minimal. In hardware projects, this behavior is often seen as a theorem, and it is essential for hardware teams to keep this principle in mind when planning and executing their projects. By identifying potential changes early in the development cycle, hardware teams can minimize the costs and time required to implement changes and ensure that their projects are completed within budget and deadlines.

As you may have noticed, there is an obvious waterfall approach in this development process. This approach is necessary because each stage builds upon the previous one. It is impossible to test the PCB without completing the PCB layout, and any changes that would affect the outputs of the earlier stages can have a large impact on the entire project and be challenging to implement, even if they are minor. In software development, solving a bug after deployment is not as catastrophic as it is in hardware development. Imagine throwing away three months of work because you messed up between mils and millimeters when drawing a footprint, that's HARDware.

However, it's worth noting that this stages and phases approach for hardware development doesn't mean that the process is inflexible. In fact, agile development methodologies can be applied to the PCB development process, allowing for more flexibility and adaptability.

Episode IV: A New Scrum

Scrum might be the most popular methodology to apply the Agile framework for developing software. But wait, I've just said that change is a scary word for some stages of a hardware project. How can an iteration, change-driven philosophy be merged with the waterfallish approach of hardware development? Let's open a PR!

Implementing scrum in hardware development is harder than software. Some observations on why it's harder:

1) Hardware is harder to modularize and split into small independent tasks.

Reason: Hardware design is de-facto highly coupled. Solution: Always implement a hierarchical block design and focus on defining your hardware module interfaces first. This approach will allow for smoother change management and make it easier to split the team and assign members to specific blocks and integrations.

2) A single product feature usually needs more than one hardware module defined.

Reason: In hardware development, it's harder to apply sprints focused on features since a single feature might require a set of product assemblies completely developed. Solution: Focus the sprints on designing a complete product assembly, such as a hardware module, rather than delivering individual product features. By delivering functional hardware components at the end of each sprint, the team can build a functional system in incremental steps, which can help manage complexity and minimize the risk of project failure.

3) Change cost increments over time.

Reason: Change management in hardware development might be more difficult and costly than in software development. A late-stage change can result in significant rework, delay, and additional costs. Solution: Having a well-defined hardware architecture with clear interfaces and modular blocks can enable the team to manage changes more effectively. When changes occur, the team can update the affected blocks and review the changes in isolation before integrating them with the rest of the system.

4) Partial functionality demonstrations are difficult to achieve.

Reason: Demonstrating partial functionality in hardware development is challenging, unlike software development where it's possible to quickly demonstrate partial functionality through prototyping or mocked functionalities. Solution: Build preliminary prototypes of specific subsystems or modules. In this way, the team can demonstrate partial functionality and validate design assumptions.

5) Hardware testing.

Reason: Hardware testing typically requires fewer test cases compared to software, however, it usually requires specialized and expensive equipment, such as oscilloscopes, logic analyzers, and signal generators. Solution: While test-driven development may not be feasible in hardware development, a well-defined testing plan with clear acceptance criteria and test cases can help ensure quality and reduce the risk of failure.

6) External dependencies.

Reason: Hardware projects have external dependencies, such as mechanical components design, manufacturing and assembly process, test equipment, and supply chain. Solution: By identifying external dependencies early in the project, the team can better plan and coordinate with external stakeholders, adjust timelines accordingly, and minimize delays.

7) Specialization.

Reason: Hardware development often requires specialized skills, and it can be difficult to complete critical tasks if only one team member has the required expertise. Solution: Cross-training team members and rotating tasks can help ensure that critical tasks can be completed, even if team members leave or become unavailable.

As a final note, it's worth mentioning that the market for hardware development outsourcing services is rapidly expanding, with offshore companies taking advantage of globalization to design, manufacture, and test small quantities of prototypes quickly. This trend creates new opportunities for hardware design, but it also increases competition, making it more challenging to stand out in the market.

Therefore, having well-defined and proven management tools and strategies is essential for delivering high-quality products within the intended timeline and budget. It is also crucial to have a motivated team willing to go the extra mile to develop an outstanding product.