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
A string describing current version of the software
An Alphanumeric unique indentifier of the bulb.
Specify whether bulb is currently powered on/off
A hex value describing current color of the light
Intensity of the light.
A user assigned string identifying bulb's location
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 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.