For those new to the concept of IoT devices and IoTWorX, we present definitions for the terms used in this product documentation.
ICONICS IoTWorX Scenario
The IoT Hub is a Microsoft Azure Service. It provides secure device-to-cloud communication, secure cloud-to-device configuration and acts as a short-term repository for data publishing.
ICONICS IoTWorX is the ICONICS-developed software product that resides on the selected hardware device. It provides southbound communication, utilizing BACnet, Modbus, OPC or SNMP as well as northbound publishing via AMQP transport protocol.
The Transport Protocols that ICONICS utilizes help establish the Publish/Subscribe (or Pub/Sub) communications method between devices and the cloud. Two integral protocols are AMQP (Advanced Message Queuing Protocol, which is bidirectional) and MQTT (Message Queuing Telemetry Transport, which is outbound only) defined below.
Advanced Message Queuing Protocol AMQP is a binary application layer protocol that was created to substantiate a vast number of messaging applications and communication designs. It provides flow-controlled, message-oriented communication with built-in options for message delivery guarantees, as well as authentication and/or encryption based on widely accepted Internet authentication and data security protocols such as Simple Authentication and Security Layer (SASL) and/or Transport Layer Security (TLS). AMQP is the primary transport layer protocol used by the Azure IoT Hub, and is the default transport layer for ICONICS IoTWorX, as it supports read and write functionality for command and control of industrial and building automation equipment.
The OPC Foundation has also identified AMQP as one of its protocols of choice upon which to build a reference implementation of Enterprise Service Bus (ESB) connectors, which serves as the basis for its IoT platform. As a charter member of the OPC Foundation, ICONICS plans to support AMQP because of its efficient design, which is optimized for messaging between devices.
Message Queuing Telemetry Transport (MQTT) is a protocol that was specifically created for SCADA systems and their related networks. It uses a publish/subscribe mechanism to minimize the payload and overhead with application-specific, custom JSON or binary formats. MQTT is widely accepted in IT departments worldwide, with many open source examples available in just about any programming language. ICONICS recommends using MQTT when network bandwidth is at a premium, and always with a secure communication method such as TLS.
Integration with Azure IoT/Cloud Solutions
Various components are installed as part of ICONICS' IoTWorX, including the Communicator, Visualizer, Cloud Connector, Collector and Analyzer components.
The Communicator includes ICONICS FrameWorX Server which, in addition to integrating with certain communications protocols (based on version), also utilizes Expressions and a data Simulator. The Communicator includes integration with SNMP, Modbus, and OPC UA. The Communicator also works with ICONICS System Health Monitor service.
A connected IoT Data Engine takes the data (the selected tags) that is to be published and sends it to the Cloud Connector and on through to the IoT Hub.
The Visualizer is a simplified data visualization piece, similar to KPIWorX, on the IoT device box, that is behind the firewall only (not allowing connection from devices outside of the internal network).
The Cloud Connector is a software layer within IoTWorX to publish data into the cloud.
The Hyper Collector is a data historian that will store data locally on the IoT device box itself. Users can specify the following:
History Collection Rate
Whether to make the stored data available for local playback in IoT Visualizer
Whether to send the locally stored data to the cloud
Tags to Log - via a separate Publish list
Schedule for Writing the Collected Data to Hyper Historian in Azure Cloud - via a new Scheduler component
Type of Hyper Historian Connection - either Direct or Via IoT Hub
The Analyzer provides edge analytics capability that performs calculations on the IoT device box itself (on the "edge"). The Analyzer can "pre-calculate" rather than sending all the information directly into the cloud for analysis there instead.
See Also: