Connected Factory Quick Start Pre-flight Your Factory Code In The Lab
It is essential that you test your configuration of the Connected Factory Process before you go into production. Fortunately, this can be done very easily in your lab in a way that works exactly as you will be working in a production environment. This lab-based testing, enabled by impCentral™, allows you to thoroughly check your factory firmware and its operation with BlinkUp™ fixtures and Devices Under Test (DUTs).
Additionally, the test process yields blessed devices. This means that you can also fully test device activation and configuration using not only the BlinkUp SDK-based configuration app that you will be providing to your end-users but also the very type of devices which your end-users will activating.
Note Lab testing does not eliminate the need to verify the process within your chosen factory. Physical differences between the two environments, and differences with their respective networks and Internet connectivity, mean that you still need to verify the process in both locations. But thorough testing in the lab can save considerable time and cost later on — especially if your factory is in another country, on another continent.
impCentral provides all the tools that you need to set up factory testing, but before we begin, let’s quickly review the components we’ll use. The Connected Factory Process has four key components: application firmware, factory firmware, one or more BlinkUp fixtures, and a number of DUTs.
You develop and test your application firmware within an impCentral Development Device Group. You then make it available for production, a process called Promotion. In the Connected Factory Process, promoted application firmware is deployed to Production Device Groups to which DUTs are assigned upon blessing.
This guide assumes you have already developed and tested your application firmware but have not yet promoted it. You will need to do so for testing; we will show you how in a moment.
Factory firmware is developed in impCentral within a Test Factory Device Group. Factory firmware is used to drive BlinkUp fixtures and to test DUTs on the assembly line to ensure they meet your specification. If the DUTs pass these tests, your factory firmware will prepare them to receive their application firmware.
A BlinkUp fixture performs BlinkUp in the factory or the lab to provide DUTs with the factory enrollment token they need to authenticate themselves to the Electric Imp impCloud™ and with local network access credentials, as required. Once enrolled, DUTs receive the factory firmware. In the test environment, fixtures assigned to Test Factory Device Groups are able to configure DUTs just they do in the factory.
Note We recommend that you work in the lab with the same kind of fixture that you’ll be using in the factory, such as Electric Imp’s impFactory™ appliance. This allows you to better understand the physical positioning of fixtures and DUTs.
Your test fixture should first be assigned to your Electric Imp account using the Electric Imp mobile app. It will then need to be assigned to a Factory Test Device Group. We will do this shortly.
In the factory, DUTs are newly assembled units that are ready for testing and, if the tests pass, blessing. In the lab, your DUTs might be hand-assembled units made specifically for testing or units that have come off the assembly line but have not yet been blessed.
Blessing is the procedure by which DUTs are marked as ready for end-use: they are assigned to a Production Device Group and so receive the application firmware already deployed to that group. At this point, DUTs become Production Devices. Blessing is the ultimate goal of the Connected Factory Process. In the test environment, when DUTs are blessed they are instead added to a Test Production Device Group that you have created for this purpose.
In impCentral, a Product has separate development, test production areas. The development and testing of application firmware takes place in the Development Zone. It is here that you will have already created a Development Device Group to write your application firmware and test it on one or more development devices. We will look at the Production Zone in the next guide in this series, ‘How To Implement The Connected Factory Process’.
In your list of Development Device Groups, locate the group containing your application firmware and click Deployments under MANAGE. Find the most recent deployment (it will be at the top of the list) and click Settings under MANAGE. The Deployment Settings panel will appear — make sure the Promoted box is checked. We recommend adding a description as it will help you distinguish one promoted deployment from another later on; you can also note the deployment’s SHA, and the date and time of deployment. Now click the Update button:
Test Production Device Groups are created and worked with in impCentral’s Test Zone. You can select the Test Zone using the switch in the navbar:
Click the Create New Device Group button at the top-right of the window. In the panel that appears, give the new Test Factory Device Group a name (for example,
Production 1.0), and select the application firmware deployment that you promoted in Step 1:
Finally, click the panel’s Create Test Production Device Group button
Test Factory Device Groups are very similar to Development Device Groups, but they have extra features to let you fully test the Connected Factory Process. Test Factory Device Groups are created and worked with in impCentral’s Test Zone. Click the Test Factory Device Groups icon in the sidebar:
Now click the Create New Device Group button at the top-right of the window. In the panel that appears, give the new Test Factory Device Group a name (for example,
Factory 1.0), and select the Test Production Device Group that you created in Step 2:
Click the panel’s Create Test Factory Device Group button and you will be taken to the impCentral code editor ready for you to enter your factory firmware’s first draft. You can write your own or use our sample code, which was written to use the impFactory fixture. Paste the agent and device code components into the code editor’s fields then click Build and Force Restart.
As you are already in the Test Factory Device Group’s code editor, click the Assign Devices button and select the fixture from the list presented:
Power up your BlinkUp fixture so that it connects to your network and receives the deployed factory firmware.
Now power up a DUT, align its photosensor with the fixture’s BlinkUp transmitter, and trigger BlinkUp.
If all goes well, the DUT’s BlinkUp status LED will light solid green to indicate successful test blessing. The DUT will be added to the Test Factory Device Group’s target Test Production Device Group. Click on Test Production Device Group icon in the sidebar and then Devices under MANAGE to view the list of the Test Production Device Group’s devices. From here you can view a test-blessed device’s logs.
Note Open the Test Factory Device Group’s code editor to view the logs posted by the BlinkUp fixture.
If the DUT’s LED is red, test blessing has failed for some reason — check the troubleshooting section, below.
Unsuccessfully blessed DUTs can be re-used in further testing as they are. Successfully test-blessed devices can also be re-used, but you will need to unbless them first. This can be achieved by selecting My Development Devices from the devices menu (), and then locating your test-blessed device(s). For each one you want to unbless, click Delete under MANAGE. Deleting removes a device from your account; in the case of test-blessed devices, it also returns them to an unblessed state ready to be re-blessed with your test fixture. You will be asked in a pop-up to confirm your decision: click on the Delete button to do so.
The ideal outcome of your tests will be one or more test-blessed devices. If your DUTs are not being blessed, there are a number of points at which an error might have occurred. The first is a Factory BlinkUp failure — the DUT wasn’t configured correctly or did not receive the signal — and the second is a blessing (or test) failure, indicated by the DUT’s LED lit solid red.
When a DUT first connects to the impCloud, it checks whether it is running the most up-to-date version of impOS™ that it has been permitted to run. If an impOS update is available, this will be downloaded and installed now: the status LED will go solid green for the duration of the upgrade process. This is not an indication that blessing was a success — the DUT has not yet downloaded and executed your factory firmware.
The update duration is relatively short but dependent on local Internet conditions — connectivity, the presence of a proxy, etc. — so you should not assume your factory firmware will run after a measured time. The duration of the ‘BlinkUp → update → restart → test-and-bless’ cycle will likely be different between your lab and your factory.
When updating is complete, the DUT will restart, re-connect, and download and run the factory firmware — subject to the potential issues described below.
If BlinkUp failed (indicated by a fast red flash or a slow orange flash), check the physical placement of the DUT relative to the fixture’s emitter. Check that you have correctly set the LED polarity (BLINKUP_ACTIVEHIGH or BLINKUP_ACTIVELOW) in the factory firmware’s server.factoryblinkup() call. You may also wish to check the DUT’s BlinkUp circuit design and photosensor placement — is it being obscured by the casing?
If BlinkUp succeeded (three seconds of solid green followed by red and amber flashes) but the DUT doesn't connect, check the WiFi credentials embedded in or retrieved by the factory firmware and passed into the server.factoryblinkup() call.
Make sure the fixture is configured for local network access using the Electric Imp mobile app, and has been assigned to the correct Test Factory Device Group.
Note If you are private impCloud customer, you will need to use your own BlinkUp web app in development mode.
If your factory firmware includes tests of the DUT hardware, you should feed the result of those tests as a single Boolean value into the server.bless() call. This ensures that the DUT’s LED will signal red if the hardware test failed, allowing a factory operator to identify the faulty unit and remove it. As that is the same effect as blessing itself failing, your factory firmware should include log messages to help you determine where the point of failure lies. If it is in the hardware test section of your factory firmware, check the code and/or the DUT hardware manually.
Test-blessed devices cannot be immediately re-blessed, so if a DUT appears to be failing after it has already been successfully blessed, check that it is not still blessed — or that an attempt to unbless it (see ‘Re-testing DUTs’, above) was not successful.
If a DUT is connected but is not indicating bless success or failure, check that the promoted factory firmware’s blessing flow includes the key server.bless() call and that it has not been disabled for testing.
The following features are part of the connected factory process functionality and so made available for lab-based factory tests too. However, they are optional and are not required for testing or for production.
impCentral provides two event-triggered webhooks which you can use to connect the factory process to your own record-keeping systems. These webhooks are configured on a per-Device Group basis. In the test environment, they are only available to Test Production Device Groups. Webhooks are configured in the chosen Test Production Device Group’s settings: navigate to your Product’s list of Test Production Device Groups, then click on Settings under MANAGE for the required group.
The two webhooks are:
To configure either webhook, provide the URL of an endpoint on your server, a third-party logging service, or even a development device’s agent. The Electric Imp impCloud automatically posts an HTTP request with a data payload in JSON format to the endpoint when the named event takes place:
Customers can choose when a test-blessed DUT receives its target application firmware:
The former is the default and the recommended setting as it ensures test-blessed DUTs can run application code as soon as they are powered up. However, you may choose to use the second option, and this too is set in the Test Production Device Group settings (see above).
If your factory tests have correctly yielded Test Production Devices running the specified application firmware, then you are ready to take your factory firmware and application firmware to production, and to begin manufacturing your connected product in a real factory. You should now set up your production factory flow: please see our step-by-step guide, ‘How To Implement The Connected Factory Process’.