Chip-Pivoting: Building Resilient Supply Chains Through a Modular Design Strategy

Author : Johannes Lask, SEGGER

13 October 2023

Figure 1: The modular approach of the firmware design leads to the creation of a HAL
Figure 1: The modular approach of the firmware design leads to the creation of a HAL

In this ever-evolving technology landscape, disruptions like chip shortages can cast shadows over even the most meticulously planned projects. Picture this; a thriving product assembly line suddenly halted due to the scarcity of a specific microcontroller unit (MCU) - just one a single component holding an entire process hostage and potentially causing huge cost problems as a result. 

This article looks at what can be done to future proof OEM production.

In a world where the pace of technological advance rivals its unpredictability, mastering disruptions of this kind becomes imperative. Addressing this challenge is the concept of ‘chip-pivoting’, which can be readily achieved using modular hardware and firmware, along with an applicable operating system (OS). 

Diversifying component sources
The best strategy for addressing the risk of key component scarcity is to start the necessary considerations right from the design phase. One or more alternative component brands for the bill-of-materials (BoM) should be identified, in order to manage the supply channel and minimise the possibility of shortages arising.

However, it is not always possible to find a second source for a component. For MCUs and microprocessors in particular, it is very difficult - given the complexity of the hardware and the numerous features involved. Therefore, the prospect of MCU shortages should not be managed by second supply sources, but by the ability to replace them with other devices possessing similar performance and functionality.

Figure 2: The modular approach of the firmware design implemented with SEGGER’s emPower OS
Figure 2: The modular approach of the firmware design implemented with SEGGER’s emPower OS

Chip-pivoting is an activity that heavily impacts on R&D resources, as it requires hardware, firmware and software changes. To simplify this, adopting a modular approach in the design phase is crucial for both hardware and firmware.

Efficient hardware modularity for seamless chip-pivoting
In traditional design approaches, where the technical fit is the first driver, all functionalities are placed in one main PCB. However, a chip-pivoting strategy applied to this scenario requires the complete, and costly, redesign of the board and almost all the firmware. In contrast, taking a modular approach, for both hardware and firmware, allows a pivot to be handled in much less time and at a far lower cost.

With the modular design of the hardware, the MCU and its main accompanying components (memory, PMIC, etc.) are located on a system-on-module (SoM) or a micro-SoM (µSoM).  The main advantages are greater complexity in a small space (a PCB with several layers will be more compact) and the MCU changing impact is shifted to just the SoM/µSoM, leaving the rest of the board unchanged. The hardware modifications also require a revision of the product certifications, but the timely modification of a SoM/µSoM also lessens the risks involved from this point of view.

Implementing a modular firmware approach 

Redesigning hardware is a vital aspect, but a firmware redesign can be equally time-consuming. MCUs and peripherals require software components that must align with both the hardware and firmware application. While a chip vendor’s software development kit (SDK) can provide all required functionality for the initially used MCU, usually it cannot be applied to other controllers. If an SDK is tightly coupled to the user application, the entire firmware will need redesigned when another chip is specified.

Figure 3: Swapping to another driver package while the user application as well as the emPower OS components remain unchanged
Figure 3: Swapping to another driver package while the user application as well as the emPower OS components remain unchanged

To mitigate that risk, the strategy for software can be the same as for hardware, namely using a modular approach and building on software components that are hardware independent. A modular approach for the firmware design leads to the creation of a hardware abstraction layer (HAL), above which the firmware does not suffer any impact in terms of chip-pivoting (see Figure 1). If the pivot takes place inside the same architecture, for instance Arm Cortex-M4, the compiler typically remains the same. However, the interface layer with the hardware and the specific drivers that are strictly related to the designated peripherals inside the MCU must be adapted. So, the pivot requires new off-the-shelf drivers, or in the worst case, a modified board support package, and recompiling of the otherwise unchanged firmware. The new hardware gets a tailored firmware release, yet the customer application, typically within a virtual machine, remains unaffected.

Figure 2 shows the firmware modularity approach applied to a real use case, with SEGGER’s libraries and RTOS implemented in emPower OS. The HAL is composed of SEGGER libraries and proprietary drivers. In this case, only the drivers have to be changed, making chip-pivoting simpler and less expensive.

Flexibility by default
When it comes to chip-pivoting, success lies in modular hardware and software design. That’s where SEGGER’s emPower OS comes into play. This is a modular OS solution, with all software components developed by in-house and designed to seamlessly fit together in any combination. Using embOS as the underlying RTOS, emPower OS includes software stacks for communication and connectivity, a file system, plus graphical user interface (GUI) libraries. Moreover, it incorporates classes and protocols, as well as security/cryptography modules - so as to provide the building blocks for modern embedded applications.

Each module is pre-configured to establish tasks and allocate resources, and includes readily set-up interface layers to enable component interconnection. Most importantly, all software components that directly or indirectly require additional hardware components use well-defined driver interfaces and configuration layers.

With emPower OS, the driver interfaces and configuration layers separate the core components and the user application from the underlying hardware. In the initial product design phase, a firmware project can be implemented using an emPower OS driver package matching the hardware. If at any point in the product lifecycle the target MCU or other components need replacing, they can be easily swapped to another driver package while both the user application and the emPower OS components remain unchanged (as illustrated in Figure 3).

Figure 4: How emPower OS preserves suppliers from production halt
Figure 4: How emPower OS preserves suppliers from production halt

Scalability and licensing flexibility
In addition to providing counter measures for obsolescence and supply shortages, emPower OS can also accommodate hardware iterations and new feature versions of a product or product family. All emPower OS components are highly configurable to either require the least amount of space to fit on tiny single-core MCUs or to enable additional speed optimisation when running on larger or more complex application controller systems. Flexible licensing also provides various options to suit development team requirements. 

Safeguarding against production halts
To review how to mitigate the risk of production hold-ups, Figure 4 shows several different possible scenarios.
 
In scenario 1, the decision is made to increase stock and wait until the shortage is over. In scenario 2, the product is redesigned with a different chip and new software. In scenario 3, the product is redesigned and the software switched to emPower OS. In scenario 4, the product already uses modular hardware and emPower OS. 

Deciding to wait it out might cause production to be halted for quite a while, until the required chips become available again, resulting in potentially significant losses in revenue and market share. A hardware and software redesign might shorten the time until production can resume. However, such redesigns could take longer than expected and may not be ready when production comes to a halt. Scenario 3 shows that even when the hardware is redesigned, emPower OS can provide a significantly shorter development cycle thanks to its extensive hardware support. If emPower OS is already used in the firmware, and the hardware is modularly designed, it might be possible to completely avoid a production halt. The redesign on the software side can be reduced to merely switching a few drivers, adapting the configuration for direct hardware access, then testing the functionality.

Conclusion
In the face of unprecedented disruptions, chip-pivoting has emerged as a viable solution through the utilisation of modular hardware and software. By embracing modular design, companies can adapt to chip shortages swiftly and cost-effectively, avoiding the need for extensive hardware/firmware rework.


Contact Details and Archive...

Print this page | E-mail this page