IoT Simulator 2.0 Release

IoT Simulator 2.0 Release

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.

IoT Network simulator for AWS IoT core / Azure IoT hub

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.

Try the new IoT Simulator 2.0 now

download now

 

Sparkplug B MQTT Simulation

Sparkplug B MQTT Simulation

Sparkplug provides an open and freely available specification for how Edge of Network (EoN) gateways or native MQTT enabled end devices and MQTT Applications communicate bi-directionally within an MQTT Infrastructure. One of the unique aspects of MQTT is that it was originally designed for real time SCADA systems to help reduce data latency over bandwidth limited and often unreliable network infrastructure.  Similarly the intent of the Sparkplug specification is to take full advantage of MQTT’s native Continuous Session Awareness capability as it applies to real time SCADA/IIoT solutions.

Specifications of Sparkplug

 

Currently there are two Sparkplug defined encoding schemes that this specification supports.

  • Firstly the Sparkplug A encoding scheme based on the very popular Kura open source Google Protocol Buffer definition.
  • Secondly the Sparkplug B encoding scheme that provides a richer data model developed with the feedback of many system integrators and end user customers using MQTT.

Sparkplug MQTT Topics and Messages

 

This blog guide you to simulate the Sparkplug B encoding in Bevywise IoT Simulator. Before simulating you must know about the Sparkplug Topic Namespace Elements and Sparkplug MQTT Message Types. 

Sparkplug Topic Namespace Elements:

All Clients which use the Sparkplug spec will use this default UTF-8 Format Topic namespace.

namespace/group_id/message_type/edge_node_id/[device_id]

  • namespace: It is the root element that will define both the structure of the remaining namespace elements as well as the encoding used for the associated payload data. Format for namespace is UTF-8 string constant should be used. Similarly  the current Sparkplug specification defines two namespaces:
  • Sparkplug payload definition A
  • namespace element should be “spAv1.0”
  • Sparkplug payload definition B
  • namespace element should be “spBv1.0”
  • group_id: This provides unique logical group ID of MQTT EoN nodes. For group_id the format should be  UTF-8 alphanumeric string, except for the reserved characters of ‘+’ (plus), ‘/’ (forward slash), and ‘#’ (number sign). Examples of where the [group_id] might be used include Cement industry where MQTT EoN nodes on different department have the different [group_id].
  • message_type Element: It provide the indication as to, how to handle the MQTT payload of the message. The following message_type elements are defined for the Sparkplug Topic Namespace:
  • NBIRTH – Birth certificate for MQTT EoN nodes.
  • NDEATH – Death certificate for MQTT EoN nodes.
  • DBIRTH – Birth certificate for Devices.
  • DDEATH  – Death certificate for Devices.
  • NDATA    – Node data message.
  • DDATA     – Device data message.
  • NCMD – Node command message.
  • DCMD      – Device command message.
  • STATE – Critical application state message.
  • edge_node_id: Unquie identification for the MQTT EoN nodes within the infrastructure. For edge_node_id the format should be UTF-8 alphanumeric string, except for the reserved characters of ‘+’ (plus), ‘/’ (forward slash), and ‘#’ (number sign). The edge_node_id travels with every message published, so it should be as short as possible
  • device_id: Unquie ID which used to identify the device attached to the MQTT EoN node. device_id is an optional element since some messages will be either originating or destined to the edge_node_id, in that place device_id would not be required. The format of the device_id is a valid UTF-8 alphanumeric String except for the reserved characters of ‘+’ (plus), ‘/’ (forward slash), and ‘#’ (number sign). The device_id travels with every message published, so it should be as short as possible.

Simulate Sparkplug MQTT Device & Network

  • Bevywise IoT Simulator is a simulation tool which help users to test and develop the MQTT/IoT Applications. For installation and setup of Bevywise IoT Simulator, please refer our help doc and video tutorial.
  • After starting the Simulator, create a new network.
  • In new network, create three MQTTEoN nodes by via device creation : spBv1.0, Node2, Node3.

Sparkplug MQTT Message Types

 

Sparkplug defines the Topic Namespace for set of MQTT messages that are used to manage connection state as well as bidirectional metric information exchange that would apply to many typical real-time SCADA/IIoT, monitoring, and data collection system use cases. The defined message types include:

  • NBIRTH – Birth certificate for MQTT EoN nodes.
  • NDEATH – Death certificate for MQTT EoN nodes.
  • DBIRTH – Birth certificate for Devices.
  • DDEATH  – Death certificate for Devices.
  • NDATA    – Node data message.
  • DDATA     – Device data message.
  • NCMD – Node command message.
  • DCMD      – Device command message.
  • STATE – Critical application state message.

Advantage of using these defined messages:

Using these defined messages the SCADA/IIOT Application can:

  • Initially Discover all metadata and monitor state of any EoN/Device connected to the MQTT infrastructure.
  • Then Discover all metrics which include all diagnostics, properties, metadata, and current state values.
  • Issue write/command messages to any EoN/Device metric.

Creating Sparkplug MQTT Message types in IoT Simulator

 

MQTT EoN NBIRTH and NDeath Certificate: The first MQTT message that an EoN node MUST publish upon the successful establishment of an MQTT Session is an EoN BIRTH Certificate.

Creating NBIRTH: [namespace/group_id/NBIRTH/edge_node_id]

  • Click spBv1.0 and
  • Create a event with “Whole day” configuration with every 5 sec time interval.
  • In that give the topic namespace as

spBv1.0/kiln/NBIRTH/1

  • Select QoS as 1 and retain as 1
  • Give message as “NBIRTH” and save it

Creating NDEATH: [namespace/group_id/NDEATH/edge_node_id]

  • Click spBv1.0 and
  • Create a event with “On Disconnect” configuration.
  • In that give the topic as

spBv1.0/kiln/NDEATH/1

  • Select QoS as 1 and retain as 1
  • Give message as “NDEATH” and save it.

MQTT EoN Node Data (NDATA)

  • Once an MQTT EoN node is online with a proper NBIRTH, the NDATA will published.
  • This enables the advantages of the native Continuous Session Awareness of MQTT to monitor the STATE of all connected MQTT EoN node and to rely on Report by Exception (RBE) messages for metric state changes over the MQTT session connection.
  • The payload of NDATA messages will contain any RBE or time based metric EoN node values that need to be reported to any subscribing MQTT clients.

Creating NDATA:[namespace/group_id/NDATA/edge_node_id]

  • Click spBv1.0 and
  • Click the + icon and select Behaviour
  • In that, give command topic as “NBIRTH topic namespace” and command “NBIRTH”.
  • Next give the NDATA topic namespace in Event and give Event Data as current time and click save.

spBv1.0/Kiln/NDATA/1

  • Now NDATA will published to subscriber once they subscribe the NDATA topic namespace.

Device Birth Certificate[DBRITH]

  • The MQTT EoN node is responsible for the management of all attached physical and/or logical devices. Once the EoN node has published its NBIRTH, the customers application ensure that EoN Node is ONLINE
  • But each physical and/or logical device connected to this node will still need to provide this DBIRTH before consumer applications create/update the metric structure (if this is the first time this device has been seen) and set any associated metrics in the application to a “GOOD” state.

Creating the DBRITH:[namespace/group_id/DBIRTH/edge_node_id]

  • Click spBv1.0 and
  • Click the + icon and select Behaviour
  • In that, give command topic as “NBIRTH topic namespace” and command “NBIRTH”.
  • Next give the DBIRTH topic namespace in Event and give Event Data as DBIRTH and click save.

spBv1.0/Kiln/DBIRTH/1

  • Now DBIRTH will published to subscriber once they subscribe the DBIRTH topic namespace.

Device Data Messages (DDATA):

  • Once an MQTT EoN node and associated devices are all online with proper Birth Certificates it is in a mode of quiescent Report by Exception (RBE) reporting of any metric that changes.
  • It take advantage to monitor the STATE of all connected devices and can rely on Report by Exception (RBE) messages for any metric value change over the MQTT session connection.
  • Creating DDATA: [namespace/group_id/DDATA/edge_node_id/device_id]
  • Click spBv1.0 and
  • Click event with “Specific Duration” for 20 min duration with 10 sec interval.
  • In that give the topic as

spBv1.0/kiln/DDATA/1/LSM213

  • Select QoS as 1 and retain as 1
  • Give Random message as “ON|OFF” and click save.

Device Death Certificate[DDEATH]

  • If the device becomes unavailable for any reason (no response, CRC error, etc.) it is the responsibility of the EoN node to publish a DDEATH on behalf of the end device.
  • Once the DDEATH certificate published, any MQTT client subscribed to this device should set the data quality of all metrics to “STALE”.

Creating DDEATH:

 [namespace/group_id/DDEATH/edge_node_id/device_id]

  • Click spBv1.0 and
  • Click the + icon and select Behaviour
  • In that, give command topic as “DDATA topic namespace” and command “OFF”.
  • Next give the DBIRTH topic namespace in Event and give Event Data as DDEATH and click save.

spBv1.0/Kiln/DDEATH/1

  • Now DDEATH will published to subscriber once they subscribe the DBIRTH topic namespace based on the DDATA.

SCADA/IIoT Host Birth and Death Certificates

  • The SCADA/IIoT Host Node is any MQTT Client application that subscribes to and publishes messages.
  • In an infrastructure, mulitple MQTT Servers provide redundancy and scalability, for that MQTT EoN nodes need to be aware of the “state” of the primary SCADA/IIoT Host application(s).
  • The “state” can be acheived by the unique set of Birth/Death Certificates that the SCADA/IIoT Host MQTT Client MUST publish when a new MQTT session is established.
  • Topic namespace for SCADA/IIOT Host : STATE/scada_host_id
  • It uses an aspect of the MQTT transport called a “RETAINED” publish to maintain the current state of the Primary Host MQTT Client session state to all available MQTT Servers.
  • The format of the scada_host_id can be valid String with the exception of the reserved characters of ‘+’ (plus), ‘/’ (forward slash), and ‘#’ (number sign).

Creating SCADA/IIoT Birth Certificate Payload (STATE):

  • Click the SCADA/IIOT and
  • Create events with “On Connect” configuration.
  • In that give topic as SCADA/IIOT Host topic namespace[STATE/scada_host_id]: STATE/SCADABIRTH
  • Set WILL Retain flag as “1” and QoS as “1”
  • Select message type as “Text” and variant as “Constant”.
  • Give Payload or message as “ONLINE“.

SCADA/IIoT Host Death Certificate Payload (STATE):

  • When the SCADA/IIoT Host MQTT client establishes an MQTT session to the MQTT Server(s), the Death Certificate will be part of the Will Topic and Will Payload registered in the MQTT CONNECT transaction.
  • The Will Topic should be: STATE/scada_host_id

Creating SCADA/IIoT DEATHCertificate Payload (STATE):

  • Click the SCADA/IIOT and
  • Click the switch button straight to WILL
  • In that give topic as : STATE/SCADADEATH
  • Give message or payload as “OFFLINE”
  • Set WILL Retain flag as “1” and QoS as “1”

MQTT EoN Node Command (NCMD) 

  • The NCMD command topic provides the Topic Namespace used to send commands to any connected EoN nodes.
  • This means sending an updated metric value to an associated metric included in the NBIRTH metric list.
  • Topic namespace: namespace/group_id/NCMD/edge_node_id

Creating MQTT EoN Node Command (NCMD)

  • Click spBv1.0 and
  • Create event withInstant command
  • In that give topic as

spBv1.0/Kiln/NCMD/1

  • Set QoS to “1” and Retain to “1”
  • Select message type as JSON and click + button.
  • In that add NBIRTH metric like:
  • ONLINE_STATE and ONLINE TIME.
  • Give the Key as ONLINE_STATE, select “constant”, give value as TRUE and click ADD
  • Next click + button and
  • Give Key as ONLINE_TIME, select “System variable” and select “$Current_time from list
  • next click ADD and save the JSON.
  • Once the NBIRTH occurred, publish the NCMD by clicking the action icon
  • on the left side, now the NCMD will send commands to connected EoN nodes.
  • Next the subscribe the NCMD topic in SCADA/IIOT to get the Update metric from spBv1.0.

Device Command (DCMD)

  • The DCMD topic provides the Topic Namespace used to publish metrics to any connected device.
  • This means sending a new metric value to an associated metric included in the DBIRTH metric list.
  • Topic namespace: namespace/group_id/DCMD/edge_node_id/device_id

Creating Device Command (DCMD)

  • Click spBv1.0 and
  • Create event with “Instant command
  • In that give topic as

spBv1.0/Kiln/DCMD/1/LSM213

  • Set QoS to “1” and Retain to “1”
  • Select message type as JSON and click + button.
  • In that add NBIRTH metric like:
  • ONLINE_STATE and ONLINE TIME.
  • Give the Key as ONLINE_STATE, select “constant”, give value as TRUE and click ADD
  • Next click + button and
  • Give Key as ONLINE_TIME, select “System variable” and select “$Current_time from list
  • next click ADD and save the JSON.
  • Once the DBIRTH occurred, publish the DCMD by clicking the action icon
  • on the left side, now the NCMD will send commands to connected EoN nodes.
  • Next the subscribe the DCMD topic in SCADA/IIOT to get the Update metric from spBv1.0.
  • These are the Sparkplug set of MQTT Message Types that are used to manage connection state. Next connect the Bevywise IoT Simulator to built-in MQTT Broker or connect to any other MQTTBroker to start the Spatkplug Simulation. Likewise create Sparkplug message type for other Nodes.

You can get started by downloading the IoT Simulator now.

download now

Feel free to write to support for any questions.

MQTT Simulator 1.5 – Everything you need to know

MQTT Simulator 1.5 – Everything you need to know

We are happy to announce new updated MQTT Simulator which help you simulate more complex nested MQTT JSON data simulation. Here is the list of additional values the simulator can provide to your test environment.

Complex MQTT Data Simulation

Most devices today send data as nested JSON.  As more than one meaningful value is packed into a message, the real world has moved on to the JSON as a default data format on all the IoT Implementations. To enable testing of such environment, we have made the simulator to publish messages that has the same kind of JSON format. You can simulate any level of nested JSON to help you test any manager application.

Emulate Real world Device Uptime

In the Real world situation, the devices connectivity cannot be uniform due to various reasons like power , network.  And also the other device failure related circumstances. In order to replicate the same real time scenarios, we have added the Randomized start / stop of devices. You can specify the lowest possible uptime you would like to simulate in the networks. We will make sure the devices have an uptime that ranges from the specified value up till 100%.

For example, if you specify the minimum uptime as 91% in the MQTT Simulator, then the devices will have a uptime between 91% & 100%. The devices will be automatically stop and restart multiple times to maintain an uptime of the specified range. But Different devices will have a different stoppage time based on the random data. We are working on generating a report for uptime so that it can be compared with your manager applications report.  In addition, The reports will be available in the next version of the simulator.

Flexible IoT Events

90% of the world is going to be with Sensors which are going to just publish events. These sensors sends events with different variable data and variable times. The simulator can now send events On StartOn Disconnect , For a specified time duration & For the whole day with a specified time interval , at a specified time and by a manual trigger. You can add multiple events for these each criteria and each event can have unique complete JSON with a variable data of System defined variable, RANDOM , RANGE and LINEAR data variance. These features make the simulator event generation more versatile and robust.

Refreshing MQTT Simulator UI

The MQTT simulator UI now provides a easy to view events that are published from the device and the commands received from the manager / broker application on the user interface to make the testing much easier. The User interface also has been made more cleaner for easier overall device simulation.

The Settings of the simulator like Broker Address and Port , TLS / SSL enable , Python Interceptor and Uptime simulation has been moved to the User interface for the ease of use.

Try the latest version of the Bevywise MQTT Simulator now.

download now

We are working on integrating the simulation with the other automation tools to provide a complete test automation.

For more reference Please refer our Help document and watch our YouTube videos. 

Introducing Templates & faster IOT Simulation

Introducing Templates & faster IOT Simulation

Today we are happy to introduce iot templates & bulk device creation in IOT Simulator.

We believe that the real effort of any validation process. You have to spend the efforts on the validating and analysing the result data and not on setting up the environment.  Hence, IOT environment needs a mass network setup to test and demo the manager applications and test interoperability of devices.

IOT Templates

With the new update, you will be able to now spend very little time to just create a template. The template supports specifying a replaceable place holders strings using the client names.  Besides that, The template definition allows you to add place holders in WILL Topic, subscription topics, publishing topics and topics used in behavior pattern.

You can also use  pattern in the Data. However, the IOT simulator already supports dynamic values for the text and JSON based messages. Besides that You will be able to create tens of thousands of unique devices with unique topic and messages within a few minutes.

Multiple Simulated Networks

The validation of the manager application process have multiple process.  However, we need to review different functional implementation, performance, etc. Keeping this in mind, we have added options to store multiple simulated networks. These networks can be persisted and reused on demand.

 Download the IOT Simulator now.

download now

You can simulate large networks using affordable pricing plans. Feel free to contact us for any feedback or assistance.

Simulate dynamic messages – MQTT

Simulate dynamic messages – MQTT

We are happy to share the recent update of the IOT Simulator which can resemble a real device and  simulate dynamic messages on every message with two types of message format – TEXT & JSON.

Simulate dynamic messages

The IoT Simulator supports four types of dynamic values to be sent as part of messages.

System Variables – The messages always need to carry client specific values like Client Id, System time, etc. Besides that, the system variables help you assign these values dynamically to one of the tuple of JSON or to the Text Message.

Random – The devices often publish messages with the current states of the device. And also, These devices states are often predefined set ON | OFF or LOW | MEDIUM | HIGH or similar. Such states can be randomly generated using this dynamic type.

Range – When you want to simulate a human body temperature sensor, you often need to set a range within which the values vary. The Range can be used to simulate such scenarios. For instance, The human temperature can be set in a range of 97 deg F to 99 deg F

Constant – Every sensor need to send the details of the location of the sensor which will be fixed. Similarly For those messages, the Constant type can be used.

Download the FREE IoT Simulator now. you can simulate up to 25 devices.

download now

Feel free to contact support for any assistance or feedback.