Connectivity is embedded in the electronics ecosystem. And test should be embedded in the devices that support it.

The Internet of Things (IoT) is the new buzzword coined to describe the use of smart and connected electronic devices that enable greater efficiency and productivity in our daily lives.

These devices permeate homes, vehicles and buildings, managing security, safety, energy, inventories, even our well being. At the heart of the smart and connected electronic device is a microprocessor unit (MPU) or a microcontroller unit (MCU) that manages the device and communicates the status of its task(s) to the host of an ecosystem connected to more devices. Today an ecosystem might be a smart grid, hospital and patient monitoring, in-vehicle or vehicle-to-vehicle management. More complex ecosystems will be developed as the world gets more digitally connected.

The concept of an autonomous vehicle is a good example of such an ecosystem. It will require the car’s telematics to constantly provide its location to manage its proximity to other vehicles, pedestrians and stationary or moving objects. The powertrain, speed, steering, braking and body control units need to work in unison to prevent a collision while navigating to its destination. The electronics within the car extend from these control units to sensors and actuators mounted in various parts of the car. It is not unusual to find up to 100 16- and 32-bit MCUs in the various electronic modules installed in a single car.

The safety expected for an autonomous car will demand all electronics inside the car are of the highest quality and reliability. It will drive exhaustive testing to ensure none of the electronics malfunction, whether the car is stationary or in motion. The testing will involve operating each electronic module standalone and then connecting to its in-vehicle host to verify the communications and responsiveness.

Stringent testing already exists in the manufacturing of car electronics using imaging and electrical systems to verify printed circuit board assemblies (PCBA) prior to stressing it, or its assembled module in environmental chambers to simulate operating in extreme conditions. Today’s paradigm relies on structural test to pass a perfectly manufactured PCBA to functional test, which will exercise all the board’s functions to determine if it meets the designed specifications.

PCB real estate, speed and shrinking component packages will challenge structural test to deliver an assembly free of manufacturing defects. When a green-lighted structural-tested PCB fails at the start of functional test, halting its progress with no indication of the failure mechanism, it is usually tagged as “no trouble found.” The “no boot” tag is typically used for PCBs mounted with MPUs or MCUs exhibiting the same symptom. The incidence of “no trouble found” and “no boot” will trend upward, as electronics content and sophistication grow in autonomous cars. Similarly IoT devices in other ecosystems will mirror the challenges faced by the automotive industry.

As the cost of lower yields and scrapping “no trouble found” and “no boot” PCBA increases, the industry will be pressured into inserting embedded test between structural and functional test. The test methodologies, including embedded test, discussed in “Testing of Small Form Factor Products,” (Circuits Assembly, August 2013), can be leveraged to test IoT devices.

The success and returns on embedded test hinges on the commitment to start its development at the onset of PCBA design. A decision has to be made on how to load the embedded test code into the PCBA in manufacturing. When the PCBA powers up, should the PCBA switch to boot from the embedded test coded into the MCU memory or redirected to boot from a custom ROM device?

Next, the embedded test plan has to be set up with the objective of detecting “no trouble found” and “no boot” failures. Voltages at the power nets must be monitored as the PCBA sequences power to initialize its various circuits and functions. If the voltage of a power net dips below or exceeds designed limits, the embedded test must be halted and information of the power net, failing test and measured voltage reported. This information will assist the debug technician to trace the circuits of the failed power net to find the defect.

After the PCBA successfully sequences power to all its power nets and completes the MCU initialization, the MCU should be directed to verify its internal functions such as clocks, timers and interrupts are in working order before exercising the I/O ports and communication bus. The I/O ports and communication bus test can be loop-backs to verify the components in the circuits are functioning. Real devices can be connected to the I/O ports and communication bus to determine if the PCBA will function when integrated in a connected environment.

The value of embedded test is determined by the information provided to the debug technician tasked to repair the defect. It is imperative the information on the failure ticket should include the failing test, the PCBA function or circuit tested, the nets used in the test and the measured and expected value or bit. Any information of  use to the debug technician to quickly identify the circuit and, if possible, the net will increase the success rate of first-time fix, quickly reducing the pile of “no trouble found” and “no boot” PCBs.

A well thought-out test strategy incorporating embedded test supported by a process to begin its development in board design and equipping it with valuable diagnostic messages can be a cost-effective addition to improving manufacturing yields for the new IoT class of devices.

Mark Lau is in product marketing, Measurement Systems Division at Agilent Technologies (agilent.com); mark_lau@agilent.com.