Skip to main content

impCentral Factory Firmware 2.0

Production Accounts Now Have Device Under Test- and BlinkUp Fixture-specific Firmware

impCentral™ now supports the creation of separate code structures for the factory firmware that runs on your BlinkUp™ fixtures and on your Devices Under Test (DUTs). Previously, these two device types ran the same factory firmware, which therefore needed to be able to detect the type of device on which it was running and to perform appropriate actions accordingly. Now each of these device types can have their own, type-specific firmware to run.

This improvement allows factory firmware developers to code with confidence, knowing that a given flow will always run on the correct device type, virtually eliminating the production hold-ups that an incorrect code flow can cause, such as executing DUT-oriented testing and blessing code on a BlinkUp fixture.

This document describes the changes made to impCentral in detail and introduces a new version of our standard factory firmware that has been adapted to take advantage of the new methodology.

The New Factory Firmware Structure

Previously, factory firmware was developed in a Test Factory Device Group and deployed in production to a Factory Device Group. Instead, impCentral now has extra device group types which target DUTs and fixtures in test and production environments:

  Previous Methodology New Methodology
Environment Development and Testing Production Development and Testing Production
Device Group(s) Test Factory Factory Test Fixture,
Test DUT
Fixture,
DUT

Application firmware development and deployment to production are not affected by this change.

For any Product, each of its Test Factory Device Groups will be be renamed a Test Fixture Device Group and be paired with a new Test DUT Device Group. Both groups will contain identical copies of the code from the source Test Factory Device Group so that your factory firmware, and Connected Factory Process development and testing, can continue unchanged. BlinkUp fixture assignments will not change.

Similarly, each of the Product’s Factory Device Groups will be renamed a Fixture Device Group and be paired with a new DUT Device Group. Again, both groups will be provided with identical copies of the code from the source Factory Device Group so that your Connected Factory production flow can continue exactly as it did before. BlinkUp fixture assignments will not change.

In short, you need make no changes to your code or factory flow until you are ready to do so.

How The Code Is Used

The process of assigning devices to any of the existing and new device groups discussed above remains exactly as before. For example, consider the testing environment (impCentral’s Test Zone). You assign a BlinkUp fixture to a Test Fixture Device Group — this will receive and run the fixture firmware that you develop in the Test Fixture Device Group’s code editor.

The fixture firmware’s task is to use BlinkUp to prepare DUTs for impCloud access. Upon BlinkUp, a DUT is automatically added to the Test DUT Device Group that has been specified as one of the Test Fixture Device Group’s targets. The DUT then receives the DUT firmware that that you develop in the Test DUT Device Group’s code editor. The DUT firmware’s task is to test the DUT and then test-bless it. Upon test-blessing, the DUT is automatically assigned to a Test Production Device Group (also specified as one of the Test Fixture Device Group’s targets, as before).

When you are ready to move to production (impCentral’s Production Zone), you create Production, DUT and Fixture Device Groups, and deploy promoted application, DUT and Fixture firmware, respectively, to those groups.

Implementing The New Approach

Connected Factory Testing

  1. In your Product’s Development Zone, promote your application firmware.
  2. In your Product’s Test Zone, create a Test Production Device Group.
    • Deploy the promoted application firmware to the new group.
  3. In your Product’s Test Zone, create a Test DUT Device Group.
  4. In your Product’s Test Zone, create a Test Fixture Device Group.
    • Set the new group to target the Test Production Device Group created in Step 2.
    • Set the new group to target the Test DUT Device Group created in Step 3.
    • Create fixture firmware (or use the sample code below) in the Test Fixture Device Group’s code editor.
    • Assign BlinkUp fixture(s) to the group for testing.

Connected Factory Production

  1. In your Product’s Test Zone, promote your application firmware.
  2. In your Product’s Test Zone, promote your DUT firmware.
  3. In your Product’s Test Zone, promote your fixture firmware.
  4. In your Product’s Production Zone, create a Production Device Group.
    • Deploy promoted application firmware to the new group.
  5. In your Product’s Production Zone, create a DUT Device Group.
    • Deploy promoted DUT firmware to the new group.
  6. In your Product’s Production Zone, create a Fixture Group.
    • Set the new group to target the Production Device Group created in Step 4.
    • Set the new group to target the DUT Device Group created in Step 5.
    • Deploy promoted DUT firmware to the new group.
    • Assign BlinkUp fixture(s) to the group for production.

Updating Your Existing Factory Firmware

This process is straightforward and simply involves removing the code which determines the device type — DUT or BlinkUp fixture — on which the firmware is running. You can also remove the code for the unwanted device type: for example, in your DUT firmware, you can remove all fixture-specific code. From your fixture firmware, you may remove all code solely relevant to DUTs.

This is demonstrated in the sample code, below.

Agent Code

As before, your two types of factory firmware may also comprise agent code. This continues to run as before, but with the proviso that it needs only provide support to the type of device that it is paired with. For example, if your existing factory firmware contains responses to messages sent from DUTs and from fixtures, you can remove from, say, the DUT agent code all callbacks that are triggered by messages from fixtures because these will never be called.

Removing the unused code will make your firmware source easier to read and maintain, but because the unneeded code will never be called, you may safely choose to leave your agent code unchanged if you wish.

Sample Code

The new methodology, as it applies to factory firmware, is best demonstrated with an example. You can see the original factory firmware here; below is its modification for impCentral’s new approach.

DUT Agent Code

If you compare the new and original versions, you will see that the new one now just contains a single callback registration call which deals with "testresult" messages from the DUT: device-specific information is sent to your data logging server (its address is placed in the constant RESULTS_URL) and to the BlinkUp fixture’s agent (see below).

DUT Device Code

The code first waits until the DUT’s imp has gone idle, in order to be sure that the contents of the property imp.configparams have been set (this was previously done via the Factory Tools library). This allows the code to confirm that it is running in a factory (or factory test) environment and, if it is, to begin the test and blessing process.

Fixture Agent Code

The new code contains a single callback registration call which deals with "blinkup.sent" messages from the fixture itself. It also uses Electric Imp’s Rocky library to establish an Internet API through which it can receive data from DUT agents.

Fixture Device Code

Like the DUT, the fixture first waits until its imp has gone idle, ensuring that the contents of the property imp.configparams have been set when they are read by the code. Again, this allows the code to confirm that it is running in a factory (or factory test) environment and, if it is, to configure the fixture (for this example we are using an impFactory™ appliance)) and then to perform a factory BlinkUp operation when triggered by as assembly line operator or some automated mechanism. This also causes the "blinkup.sent" message to be transmitted to the fixture’s agent (see above).