Fundamentals
Additional Helpers
IoT platform integration
IoT Testing
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.
What is a device lifecycle?
Every IoT product has a lifecycle- i.e. various distinct software and hardware conditions. Before starting with an IoT device simulation, it's important to research and visualize the complete device lifecycle and it's corresponding state. Let's take an 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 which installs it and bootstraps for the first time. Bulb connects to the API back-end, 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 mark defective and could no longer be used to connect with App or back-end. Any attempt to access the back-end 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 indentifier of the bulb.
Power State
1
Specify whether bulb is currently powered on/off
Color Value
0x334422
A hex value describing current color 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 use 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 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.
Replacement: 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 behavior to states and transitions, lets delve a bit more into mapping this behavior into a template for the device.
Last modified 1yr ago
Copy link