How We Do It: IoT Production Testing

This is an article in a series that discuss how we at Thingsquare solve hard technical challenges in the Internet of Things (IoT) field. Earlier articles are: How We Do It: Quickly Programming Many Devices and How We Do It: Offline IoT.

So your Internet of Things (IoT) product is ready to go out the door.

You have the business case nailed down. Your prototype validated your business hypothesis. And your team have developed all the hardware and software for the real product.

What’s the next step?

Mass production.

Mass production is when your hardware gets put together and when your software gets loaded onto each device.

And inside it all there is one crucial thing that needs to happen:

Production testing.

Each device needs to be tested to make sure it works as intended. Every single device.

Why?

Because electronics manufacturing is inherently somewhat flaky. One small drop of solder that ends up at slightly the wrong location may cause that device to malfunction. Or just work poorly.

Production testing identifies the devices that don’t work. Way before your customers find that they don’t work.

In this article, we look at how production testing is done for IoT devices. And, specifically, how the Thingsquare IoT platform helps to make production testing easy.

Why IoT production testing?

All products need to be tested before being handed over to customers. Not just IoT devices.

But unlike many other products, IoT devices must be tested one by one. It is not enough to just sample a few devices here and there. Each device must be tested and found to be working.

What happens if they are not?

You end up with devices that don’t work. Devices that needs to be recalled. And disappointed customers.

How IoT production testing works

IoT production testing happens during manufacturing. After the chips have been soldered onto the circuit board. And before the electronics gets placed inside its casing.

First the electronics is tested. This is done using well-known techniques.

Then the IoT production testing starts.

All IoT devices have one thing in common: the wireless radio.

But that’s where the similarities end.

IoT devices are often quite complex and every design is different. Many have custom hardware components and custom behavior that require custom test procedures.

IoT production testing covers both the radio link and the custom procedures.

The wireless link is tested in three ways:

• The signal strength of the radio. A bad signal strength can indicate a manufacturing problem with the antenna.
• That the device can connect to the cloud.
• That the device can update its firmware over the air.

The custom tests differ depending on the requirements.

Some tests take several days, some are quick.

Many devices are battery-operated. Battery tests may take several days to run.

Other IoT devices, such as wireless thermostat controllers, are quicker to test. A test completes in under a minute.

IoT production testing with the Thingsquare IoT platform

IoT production testing is an important event in the life of every IoT device.

IoT production testing is therefore natively supported by the Thingsquare IoT platform.

Our approach uses two types of devices: the devices under test, and one test controller device. The test controller runs the show.

The devices under test move along their production line. As they come in range of the test controller, the test controller will detect that the devices are in range, invite them to its own wireless network, and ask them to run a series of pre-determined tests.

To speed things up, it is also possible to use multiple test controllers.

The tests are different for each IoT product. Some are developed specifically for their product. But the platform also supports a number of built-in tests that can be built into the test procedure.

If all tests on a device succeed, the device detaches from the test controller’s wireless network and the test controller logs the device results to the cloud. If an error is instead detected, an alarm is raised.

Test success can be determined both by a device itself and by the test controller. For example, a test that verifies whether an on-board temperature sensor works or not may try to sample the air temperature. If the device cannot properly communicate with the on-board temperature sensor, it raises an alarm. If the test controller receives a test result with a suspicious temperature reading, like −89.2 C, the test controller instead raises the alarm.

The wireless test controller decides what tests to run on each device, and ultimately decides if a device is ok for shipping or needs further investigation. The test controller hence defines the behavior of the production testing, and is designed to be easily integrated into existing production control systems.

Re-testing deployed or recalled devices

A side-effect of the built-in wireless production testing design is that devices that have already been shipped still contain the test support. This means that you can run the same production tests via the cloud to already deployed devices, or devices that have been recalled because of some problem has been found. Worried that the differential pressure sensor broke on a remote device? Run the test again!

The details: the code

Let’s get really specific now.

This is what the actual testing code looks like.

This is the code that runs in each device. It is loaded into the device’s memory as part of the manufacturing process.

Like so much other low-level code, the code is written in the C programming language.

When the system starts, we call the testing initialization code:

  thsq_prod_init();
  thsq_prod_default_commands();

Each separate test is encoded as a callback function:

static void
callback_thsq(enum thsq_reason r, const char *msg, int len)
{
  if(r == THSQ_COMMAND) {
    if(thsq_prod_code(msg, "temp")) {
      uint16_t therm1;
      therm1 = thermistor_read_adc(1);
      printf("temp: %u\n", therm1);
      if(THERMISTOR_INVALID(therm1)) {
        thsq_prod_set_error("error reading temperature %lu", therm1);
      } else {
        thsq_prod_set_progress("temp", "temp %u", therm1);
      }
    }
    if(thsq_prod_code_done(msg)) {
      leds_on(LEDS_GREEN);
    }
    /* ... */
  }
}

That’s it! The test controller should be instructed to, in addition to the default radio and external flash tests, also run the temperature test identified by the test code temp. The test controller should also verify that the logged temperature values make sense.

Conclusions

IoT production testing is a crucial step in the mass production of IoT devices. Production testing ensures that the devices that go to your customers work.

The Thingsquare IoT platform provides a built-in way to do production testing, which includes a structured way to develop test sequences for your next IoT product.

Are you looking to build your own IoT system? Check out our Internet of Things (IoT) guide and our IoT product planner to see how your specific requirements affects timeline, budget, and hardware selection.

Interested in more of this? Join our IoT newsletter!

And as always, feel free to reach out to see how Thingsquare can help make your IoT product come true!