Mapping the IoT device lifecycle
One of the first step to get started with IoT simulation is to map your device lifecycle into states and events.
Every IoT product has a defined lifecycle which takes into account the various distinct software and hardware conditions. Before starting with an IoT device simulation, it is important to research and visualize the complete device lifecycle and it's corresponding state. Let's take the example of a smart light bulb. It typically has following life stages -
Factory: A light bulb is manufactured at factory and is assigned a unique serial number. An initial firmware is installed on that bulb and a power on test is performed. Device connectivity is tested and upon verification all the test data is erased and bulb is again brand new.
User Purchase: Bulb is sold to an end customer who installs it and bootstraps for the first time. Bulb connects to the API backend, gets the information about user account and is registered with the user profile.
API Configuration: The bulb is assigned a unique identity in the backend aka Digital Twin. User uses the bulb through a mobile App. A smart home device like Alexa also controls the bulb through remote APIs.
Software Management: A software download is triggered for the bulb. The App uploads the latest firmware on it and then it reboots.
Replacement: After a while the bulb is defective or it's life runs out, user initiates a replacement. The replacement arrives and the previous profile of the bulb is reassigned to the new bulb.
Recycling: The old bulb is now marked defective and can no longer be used to connect with the app or the backend. Any attempt to access the backend service through the old bulb must now be marked a suspicious activity and should immediately be flagged.
During these stages of the lifecycle, there are several persistent parameters which are associated with the bulb. Let's take a look at them
Property | Sample Value | Description |
SW version | R9.123.1.1 | A string describing current version of the software |
Serial Number | L32112112234 | An Alphanumeric unique identifier of the bulb. |
Power State | 1 | Specify whether bulb is currently powered on/off |
Colour Value | 0x334422 | A hex value describing current colour of the light |
Intensity | 78 | Intensity of the light. |
Location | Bedroom | A user assigned string identifying bulb's location |
Lifetime | 3442 | Number of hours the light bulb has been switched on |
Even though our example of bulb was a preliminary one, we saw that managing device state could be quite challenging. Any lifecycle event on the bulb may alter one or more of its property. It's important to prepare all the lifecycle state and events in advance and then create a state diagram mapping the transition of stages. Once it is prepared, we are ready to simulate device in IoTIFY.
It is important to classify the type of the device parameters e.g. constant and variables.
E.g. Serial number once assigned can not be changed. Software version is a read only variable which usually comes from the software itself and can not be overwritten. Power State could be triggered by the user or the backend API as well and user preference may overwrite the API actions.
The device lifecycles once mapped would provide you the top level logical states of the device. A device can be in any of these states at a given point of time. Let's build a state machine out of it.
Device States for a light bulb
We have mapped the device state into three major states.
Factory: The device is manufactured, the serial number is assigned and a basic firmware is loaded on the device. Power On Self test is passed and device is shipped.
In Use: A customer purchases the devices, opens it and powers it on for the first time. Device is connected through the app and a software update is performed. Device is now mapped into user's account. In this mode, device will periodically send data to the cloud platform, receive commands from the cloud or through the local mobile app from the user. A new software update shall be installed periodically on the device.
Deactivate: The device is defective or is thrown away for recycling by the customer. The serial number should be marked invalid and device shouldn't be allowed to download software or access the cloud backend.
Now we have got some top level idea about how to map a simulated device behaviour to states and transitions, lets delve a bit more into mapping this behaviour into a test for the device.
Last modified 2mo ago