Mapping the device lifecycle

How to think about your device lifecycle and map into the templates.

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


Sample Value


SW version


A string describing current version of the software

Serial Number


An Alphanumeric unique indentifier of the bulb.

Power State


Specify whether bulb is powered on

Color Value


A hex value describing current color of the light



Intensity of the light.



A user assigned string identifying bulb's location

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.