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.
Last updated
Was this helpful?
One of the first step to get started with IoT simulation is to map your device lifecycle into states and events.
Last updated
Was this helpful?
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.
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.
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.
