Security is one of the major concerns of the IoT Manager applications. Keeping this in mind, we built the manager applications with different level of security. IoT Network Simulator is enhanced to support all manager applications based on their security practices. Similar to the previous version, the simulator supports all its options from the user interface itself.
The User interface will provide options based on the IoT applications. For example Azure IoT hub supports SAS Token and Certificate based authentication. Users will be able to create a specific network for the Azure IoT core and able to create devices that handshakes with the IoT hub based on the details specified when configuring the device. Similarly, this is possible for the AWS IOT as well.
Simulating IoT Network for Other Manager applications
For all other manager applications like Bevywise IoT Platform, Losant , and others, you will be able to specify a single certificate at the common settings page and get your devices connected to the manager application.
Device level SSL Security
Azure IoT / AWS IoT manages every device to have an unique certificate. In addition, IoT Network simulator supports configuration of the root Certificate in the settings window and ensures that you specify each and every client certificate in the device configuration screen. The WILL , QoS , retain , event messages and command messages configuration are the same as before.
Individual Device IP Address
Simulator runs on a single machine and simulates all its devices. But, The manager will be seeing all the devices from one Host (IP Address). This contradicts the realtime Simulation. In order to overcome this, the 2.0 version has added support for using Virtual IP Address. By this functionality, each simulated device will connect to the manager application from different host Address.
Bevywise IoT Simulator is a Free, highly scalable IoT Device Simulation suite that helps you simulate various scenarios needed for developing , testing and demonstrating realtime devices and managers. You can create a simulated IoT device simply from the user interface.
There are three major requirement under which the IoT Devices M2M communication can be grouped. They are:
— Failover & Redundancy
— Data Collection
— Activate Edge Actions
This article explains how we can simulate IoT Devices. The simulated IoT Device can be used along with your real devices to act as one of the missing edge devices to have a complete test environment.
IOT Device Failover & Redundancy:
Any redundancy set up needs a master and standby device. We need to propagate the IoT failure of the master to the standby device. In our scenario, we connect the master and the standby device to the broker and the standby will subscribe to the status of the master device. The broker will notify the standby device when the master goes off for the standby device to take over. This scenario can be done using two simulated IoT device.
Take an example of the Diesel Generator of a large facility. It has a master and a standby generator. The master should register a WILL Topic and message to the broker and the standby generator should subscribe to the will topic of the master. When the master Diesel generator goes down, the broker will send the message to the interested clients.
You should configure a WILL Message with a topic /facility/dg_master_status with a Open DOWN which the broker publishes on disconnect of the device.
The DG-Standby should listen to the master status and do the necessary action. This requires two kinds of action.
— Getting the Standby up and serve the need.
— Sending the status to the Facility manager.
The DB Standby should be configured with a subscription for the Will topic of the master /facility/dg_master_status . So whenever the DG Master is down, the DG Standby will receive a message to take action. The following video helps you with the subscription to the necessary topics.
As this is the simulated Standby The standby DG we need to also publish a messages saying that the Slave DB is UP. So when the DG Slave receives a messages of master down, it publishes a slave status active. You can achieve this via the Request Response..
Request Topic & Message – DG_Standby :/facility/dg_master_status : Down
Response Topic & Messages – /facility/dg_slave_status : Active
The following video helps you with the behaviour simulation.
Every decision taken today is powered by the data. The perfect decision making needs a lot of time series data. This mandates the need for collecting data from the edge device for every second or minute based on the device.
You can configure IoT Simulator to send data continuously to the broker and the interested server every second. In Healthcare , health data is necessary to record and send every second. Let us now simulate a device that records and sends data to the manager application. We need to send a messages every few seconds for the monitors.
Every 5 second is the most possible time interval for sending data. You can configure time in a very much of a flexible pattern to send every minute or every hour or particular minute of every hour or particular second of every minute and more.
IoT Device Actions:
Sensors mostly work on the data collection. But You need to process these data and to take the necessary action. The IoT Platform gives you the flexibility to aggregate and process the data. The inference from this data can trigger messages to the edge devices which can trigger actions at the edge.
We can take water level sensor and a water pump switch as an example of how we can sense data as well as take actions. In this scenario, the water pump needs to be started when the level is low and needs to be stopped when the water level is high. The water pump will also publish the current status once the the status changes. We can configure this scenario using the Event publishing and behaviour simulator as shown in the previous videos.
Hope this article helped you simulate your own IoT Device using the IoT Simulator. Do feel free to write to us if you need any assistance with your device. We do have a few advanced options like Intercepting and customisation of messages and API Control which we will talk in detail in our next article.
Download the IoT Simulator for FREE now to create your own simulated IOT device that mimics your real devices.
Bevywise IoT Platform to Connect & Monitor IoT Devices
We at Bevywise Networks are happy to announce the IoT Platform which can provide an end to end solution. We built the platform using micro services architecture. Besides that You can scale the Platform to connect millions of devices by adding more front end brokers. Each component does a specific function. And We can add any number of components into the system based on the industrial need.
The Platform is ready to use in the current state without any customisation. The inbuilt rule engine will provide capability to transform messages. And it send commands to different iot edge devices based on the status received from different devices. You can store the details of the devices and the messages published in MySQL.
We do have a complete iot client SDK and you can use it to build iot edge devices that can communicate with the Central server.
The Bevywise IoT Platform is currently is distributed via Early access and you can have a early access version by filling the form or write to [email protected]
Every smart device being built today has the software that reads data and communicate with the other devices to create a completely smart environment. It is very important to have a robust and reliable agent for a smart environment. Few best practices to develop simple, light weight agents are,
Don’t build Intelligence into Agents
The limited life batteries powers IoT devices at the periphery mostly. Agents should be programmed to run a very few procedures like listen to the event and send the data to the central server, and when the central server sends a command, the agent should trigger the event based on the command. The only code in the agent should be:
A little more to this will ruin the battery at a faster rate. Further upgrading the intelligence inside every agent is going to be a very costly deal. The best thing is to create a dump executor agent. If you are doing a MQTT based implementation, just subscribe to only one topic and publish to only one topic and the rest should be taken care by the central broker or the server behind it.
Let the Agents Sleep
Most devices work based on the event that occurs on the devices. In such a scenario, there is no need for the agent to be continuously connected to the Central server. Select a good Protocol standard that allows your agent to sleep for a stipulated time and then come back live. MQTT-SN provides this option. The agent should reconnect within stipulated time to check for messages (if any) for it from the Central server. Have a check on how critical is the data it collects and decide on the sleep duration.
Avoid local storage. Just send it
Time sensitivity of the data is increasing day by day. The sooner the data is received in the Central server, the better decisions will be made by the central big data engine. The Embrace IoT for Perfection will give a more detailed insight into the fast feedback loop
The agent is not for storing data. As soon as you get the event, send it to the central server. Aggregation of data can also lead to intermittent data loss, so Just Send it.
Set Strong Disconnection message
Disconnection of the devices is going to be a more common phenomenon with the explosion of the number of devices and other physical factors affecting the connection. The device can go out of connection due to factors like loss of power, network issue, etc., Make sure the central server or the manager or the relevant devices get notified when devices go out of connection. Set Stronger messages if the particular agent is mission critical. MQTT provides an option of WILL MESSAGES which can inform the other clients and manager if the particular client goes off.
Perfect Restart and Reconnect routine
Anything and Everything can Fail and everything will come back to life. So are the devices. Make sure you hook agent well to the start / stop routine of the device for which you program it. The central server in spite of hosted on highly available data center too is no exception to the failure rule. The agent should have a good reconnection algorithm to check the server availability. Very frequent ping to a non available server will drain the power at a faster pace.