What you’ll learn:
- How to work out a prototyping strategy that eases the transition to mass production.
- The advantages of using data from devices in the field to improve designs over time.
- How to make products more flexible and cope with shifting markets and supply chains.
Prototyping is a vital part of the electronic design process. But a prototype is not just a proof of concept: It gives you access to physical hardware to test and debug before moving the product into mass production.
More broadly, it gives engineers, executives, and anyone else invested in its success the ability to see how the final product is likely to perform in a specific application.
For engineers under pressure to reduce time-to-market and respond faster to changing customer needs, the differences between prototype, demo, and production hardware are blurring. Engineering teams that look at prototyping as part of a continuous process instead of a separate step in the design phase can better navigate the transition. Closer collaboration between design and production will help with meeting time, quality, and cost targets.
Prototyping Electronic Designs as Early and Often as Possible
Teams can use several different approaches to create working prototypes earlier, iterate the design through successive versions, and ultimately push it to initial production. These techniques and strategies include:
- Applying lifecycle-management tools such as a “digital thread” to manage changes in design throughout the project, from the start to the end of its life.
- Using iterative design not only in the prototyping phase, but also in early production to help reduce risk and enable later modifications for cost optimization.
- Adopting advanced simulation and regression testing techniques to make sure changes to the software and firmware throughout the device’s lifecycle are consistent across product generations.
- Building off-the-shelf compute and I/O modules into the design, minimizing development cost and reducing risk when moving to production.
- Coordinating with manufacturers and other engineers downstream to evaluate cost-benefit implications through launch and beyond.
Design teams can use these strategies to test the concept or implementation early, avoiding costly rework. One advantage of the step-by-step approach is that engineers can create smaller batches of hardware and then take them out in the field for testing before a commercial launch.
Upstream benefits are also possible when implementing these strategies. Changes identified after production get applied to new iterations of the product design and then vetted through new prototypes. Production and maintenance-support engineers can share feedback on their experience with each generation of the product.
The wider team can identify ways in which the design might be redone to enable more efficient manufacturing and in-field servicing. Data from service records can inform changes to circuitry and software that reduce stresses on components, boosting reliability.
The “Digital Thread”: Redefining the Electronic Design Process
This prototype-to-production-to-prototype cycle fits in with another approach to design that’s just now entering the electronic design vocabulary: the digital thread. The digital thread is alternate way of saying “all data associated with each product variant or instance on its journey from initial assembly to the end of its lifecycle.”
The digital thread captures data on the performance of the product, and it can reveal reliability and other issues with the design. This is valuable information that you can feed back into the design process. Engineers could use it to inform decisions on the software, hardware, or firmware architecture of the design. In many cases, software and firmware updates that incorporate data captured from the digital thread can help give a new lease of life to existing production hardware.
Additionally, more engineers are taking up system-level tools to help define the initial specifications for a product, using simulations to try out different control and user-interface schemes.
These virtual environments can even act as digital twins, potentially incorporating data from a digital thread. Such an approach, to some extent, mimics the development process used in a cloud environment. Before the engineering team sends updates to production software running in the field, they run the altered software in a “sandbox” in the cloud. These tests ensure software updates will not activate dormant bugs or introduce unwanted behavior.
Today, companies building Internet of Things (IoT) devices are employing similar strategies to test firmware and software changes on a combination of virtual and physical platforms before issuing over-the-air (OTA) updates.
The physical modules tend to be arranged into hardware labs called device farms that typically contain multiple copies and versions of the prototype or final product. Then, developers perform regression tests across them with each new software revision and only commit the changes to a production release if they all pass. This strategy is effective in supporting a phased transition from prototype to production.
One consequence of this less-rigid prototype-to-production design process is that the underlying hardware is constantly changing. The manufacturer may decide to replace components, change circuit designs, or even swap out entire boards from one generation of the product to the next to support improvements in cost and reliability. They may also need to redo the design due to component shortages or other supply-chain issues.
Keeping copies of these different implementations in a device farm or in virtual form as digital twins enables testing across the different variants to ensure new software doesn’t lead to bugs and other problems in certain devices.
Keeping the Hardware the Same from Prototyping to Production
In the past, design teams bought development platforms specifically for prototyping. The development hardware now available from some suppliers is equally at home in production systems. Many of the development boards on the market can be cost-effective in volume. Using the same hardware eases the transition to production, as it minimizes fewer changes before the commercial launch date.
A cost analysis may show the benefits of moving some logic and analog functions into an application-specific integrated circuit (ASIC) or replacing them with a programmable solution. To accommodate the longer design and manufacturing times of ASIC design, early production models can still use systems-on-chips (SoCs) and standard parts combined with FPGAs.
Some development platforms come with design files that support the transition to a production version. With these designs, the core building blocks remain the same, while other parts can be removed or left unpopulated without a penalty on performance. By using modules designed around standards such as the Open Standard Module (OSM), designers are able to mix custom daughterboards or carriers with standard offerings, depending on the situation.
To allow for flexibility in the transition from prototype to production, design teams should employ a strategy that minimizes software incompatibilities at each turn. To some extent, this is possible even if I/O components change in the transition to production hardware.
For example, Linux-based designs often employ the concept of a device tree. At boot, the kernel auto-discovers hardware components and matches them to drivers in its boot image. Another option is to use the digital thread to connect boot images to appropriate targets, as each instance of the target will have an associated ID and database entry. These tactics facilitate obsolescence management in long-lived product lines.
Components may be designed out during the product’s lifecycle. The software will continue to work if the system can load the appropriate driver at boot time and the application programming interface (API) employed by the driver is at a sufficiently high abstraction layer.
Manufacturers may use device trees coupled with digital twins to check how applications change across different generations of hardware. If problems emerge, tests on the different iterations can quickly pinpoint the cause of the behavior change.
Digital-twin models expedite a more in-depth analysis of how well systems are performing in the field. Utilizing data from the field captured by services such as Avnet’s IoTConnect, companies can check on the status of the systems and use what they learn to guide the development of software updates to boost performance. The PLM infrastructure coupled with a digital-thread database provides a way to deliver insights to the relevant hardware in the field.
Prototyping isn’t going anywhere, but it is evolving. By rethinking how best to transition from early prototypes to field trials to full production, designers can smooth out the process and meet increasingly tight schedules. As devices are expected to change and adapt up to the point when they’re finally retired from service, the trick is to adopt a more flexible design approach that continues through the device’s lifecycle.
