A post from our CTO, Ivo Clarysse:

Introduction

Production Line Testing (PLT) is an essential tool used in the manufacturing process of electronic devices. It ensures that each device produced meets the required specifications and functions as intended. Typically, production testing is performed on the manufacturing floor, and the tests are designed to be simple and automated, minimizing the need for manual intervention.

Developer Testing

For development teams, the testing process is different and more extensive. They typically use a variety of tools and instruments to thoroughly test their products under various conditions. However, having a PLT setup in their lab provides the ability to replicate production testing and validate the functionality of their devices before they reach the manufacturing stage.

PLT Hardware CI

PLT Hardware CI App, available on the GitHub Marketplace, integrates production-level testing into the development process, allowing developers to detect and fix issues early in the development cycle. This enables teams to test their firmware changes on a PLT in their lab, using firmware and test plans deployed from PLTcloud. This way, teams can ensure that their firmware is production-ready before it even reaches the manufacturing floor.

Usage Workflow

Let's take a closer look at how the PLT Hardware CI GitHub App works in practice using a hypothetical example of a battery-powered temperature and humidity sensor product. Assume that the development team is working on modifying the firmware to increase battery life. The change involves disabling unused outputs such as UART and only enabling peripheral sensors on-demand.

After testing the change on a device with a debugger from their development machine, the developer creates a pull request for the change. This triggers the  various Continuous Integration checks defined in the repository.

Eventually, it passes all the checks, except for the "PLTcloud" check indicating a failure during PLT Hardware CI testing.

The PLTcloud check detail page contains a link to the corresponding PLT test report.

Clicking on “View more details on PLT Hardware CI” brings up the failing test report on PLTcloud.

The test report indicates a failure in the "SENSOR" item.  It appears the production in-circuit test plan was expecting specific UART output ([Sensor:OK]) to be emitted at firmware startup, to confirm that an I2C-attached sensor was properly detected.

With the firmware change, this expected output is no longer generated by the application firmware.

To address this, the developer could for example decide to update the in-circuit test plan to verify the presence of the sensor with a Shell command against a diagnostic firmware image that is programmed before the application firmware during in-circuit testing.

The PLT test plan is thus adjusted to include the following test item steps:

Pushing that change to the pull request causes the Continuous Integration checks to be re-validated, but this time the "PLTcloud" check succeeds, and this pull request is ready for review in the knowledge that it won’t break production testing.

References

• Introducing Hardware CI - Blue Clover Devices
• PLT Hardware CI — PLT Documentation
• GitHub Apps - PLT Hardware CI
• PLTcloud Action · Actions · GitHub Marketplace