Connected Factory Quick Start Pre-flight Your Factory Code In The Lab
It is essential that you test your Connected Factory Process before you go into production. Fortunately, this can be done very easily in your lab in a way that exactly mirrors your production environment. This lab-based testing, enabled by impCentral™’s Test Zone, allows you to thoroughly check the firmware you have developed for your BlinkUp™ fixtures and Devices Under Test (DUTs).
Additionally, the test process yields blessed Test Production Devices. This means that you can also test device activation and configuration using the BlinkUp SDK-based configuration app that you will be providing to your end-users on the very type of device which your end-users will activating.
Note Lab testing does not eliminate the need to verify your Connected Factory 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’s Test Zone provides all the tools that you need to begin factory testing, but first let’s quickly review the components we’ll use. The Connected Factory Process has five key components:
You develop and test your application firmware within an impCentral Development Device Group. You then make it available for testing and/or production, a process called Promotion. During factory testing, promoted application firmware is deployed to Test Production Device Groups to which DUTs are automatically assigned when they are blessed.
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.
Fixture firmware is developed within impCentral’s Test Zone in a Test Fixture Device Group. It is used to operate BlinkUp fixtures.
A BlinkUp fixture performs BlinkUp in the factory or the lab to send DUTs the factory enrollment token they need to authenticate themselves with the Electric Imp impCloud™. Factory BlinkUp also sends local network access credentials, if required. In the Test Zone, BlinkUp fixtures assigned to Test Fixture Device Groups are able to configure DUTs just as they will in the factory itself.
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 fixture should first be assigned to your Electric Imp account using the Electric Imp mobile app. It must then be assigned to a Factory Test Device Group. We will do this shortly.
DUT firmware is developed in impCentral within a Test DUT Device Group. Once authenticated after factory BlinkUp, DUTs are automatically assigned to a Test DUT Device Group and receive the DUT firmware, which is written to test and bless each DUT on which it runs.
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 firmware 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 in the factory as ready for end-use: they are assigned to a Production Device Group and so receive the application firmware deployed to that group. At this point, DUTs become Production Devices. In the test environment, when DUTs are blessed they are added to a Test Production Device Group that you have created in the Test Zone for this purpose.
In impCentral, a Product has separate development, test and production areas, or ‘zones’. The development and testing of application firmware takes place in the Development Zone. You should 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’.
If you are not logged in to impCentral, do so now. Locate your Product in the Products list and click Development Zone under MANAGE.
In your list of Development Device Groups, locate the group containing your application firmware and click Code under MANAGE. In the code editor, click Build and Force Restart, then click Promote:
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 Production Device Group a name (for example,
TEST PD), and select the application firmware deployment that you promoted in Step 1:
Ignore the other settings for now, and click the panel’s Create button.
Click the Test DUT 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 DUT Device Group a name (for example,
TEST DUTs). Select the application firmware deployment that you promoted in Step 1:
Don’t worry about choosing application code at this point: this is just to get the group ready; you will change the code shortly.
Click the panel’s Create button. If you are not taken to the impCentral code editor ready for you to enter your DUT firmware’s first draft, just click Code under the MANAGE column for the new group. You can now write your own DUT firmware or use our sample code. Paste the agent and device code components into the code editor’s fields, replacing the application code, then click Build and Force Restart.
Click the Test Fixture 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 Fixture Device Group a name (for example,
TEST FIXT). Now select the Test Production Device Group that you created in Step 2, and the Test DUT Device Group that you created in Step 3:
Click the panel’s Create button and you will be taken to the impCentral code editor ready for you to enter your fixture 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 Fixture 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 fixture firmware.
Now power up a DUT, align its photo-sensor 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 first be added to the Test Fixture Device Group’s target Test DUT Device Group, from which it will receive and run its DUT firmware. This firmware will eventually bless the DUT; it will then be added to the Test Fixture 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 Fixture 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, or the unit’s components failed to pass your tests — 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 Production 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 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 DUT firmware.
The update duration is relatively short but highly dependent on local Internet conditions: connectivity speed, the presence of a proxy, etc. You should not assume your DUT 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 its assigned DUT 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 fixture firmware’s server.factoryblinkup() call. You may also wish to check the DUT’s BlinkUp circuit design and photo-sensor placement — is it being obscured by the casing, for instance?
If BlinkUp succeeded (three seconds of solid green followed by red and amber flashes) but the DUT doesn't connect (slow green flash), check the WiFi credentials embedded in or retrieved by the fixture firmware and passed into the server.factoryblinkup() call.
If your DUT firmware tests 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 DUT 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 DUT firmware, check the code and/or the DUT hardware manually.
Test Production 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 DUT firmware includes the mandatory server.bless() call and that it has not been disabled for testing (this is unnecessary).
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 Zone, 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 Production Device receives its application firmware:
The former is the default and the recommended setting as it ensures that Test Production Device can run their application firmware as soon as they are power cycled. 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 DUT, fixture and application firmware to production, and to begin manufacturing your connected product in a real factory. You should now set up your production flow: please see our second Quick Start Guide, ‘How To Implement The Connected Factory Process’.