2nd sourcing used to be standard practice. At one time a lot of purchasing departments could rule out the use of a component simply due to its being sole-sourced. Getting around those rules might have taken just short of an act of congress.
Today, with so many different specialized chips, it is, in many cases, simply impossible to have a second source. If you use Microchip MCUs, you can buy them from Microchip. That's it. Atmel from Atmel. An Allegro motor controller will only come from Allegro.
I do, however, think it's possible to prepare for limited disasters. With the Microchip example - say they have a major supply disruption. The supply of the particular MCU you use runs dry. Mnay of their parts maintain a lot of pin compatibility within the same pin-count packages. If your MCU is not available, they might have another close one that could do the job with minimal code changes.
Motor control chips, blue tooth and ZigBees might be more of a challenge, but the functionality is fairly standard. PCB real estate might not allow for having two different footprints, but maybe a small daughter card could fit the bill.
To be fair to Japan, the earthquake had little effect. It was really the tsunami that caused the most damage.
While having penalty clauses etc in contracts might give you a certain degree of comfort it does not help you if parts cannot get delivered. Or, put another way, it might give you someone to blame, but it does not give you a solution.
I recently had this discussion with some people and we had the idea of designing boards with overlapping footprints for key components like micros. Design for two equivalent parts from 2 vendors with supply chains in different countries. Choose one part as your primary part. If you lose that vendor then hopefully the other will survive ad you can respin your product quickly.
I live in Christchurch NZ where we got hammered by earthquakes. Luckily we didn't lose much manufacturing.
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Are the design challenges the same as with embedded systems, but with a little developer- and IT-skills added in? What do engineers need to know? Rick Merritt talks with two experts about the tools and best options for designing IoT devices in 2016. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.