Industrial Monitoring, Dashboards and Alerting
We have a number of customers who are using FRED as a cloud service to monitor and manage factory and other industrial machinery. A popular approach is to use an OPC server, or similar gateway device to gather machine data and deliver it, via MQTT (or sometime HTTP) to FRED.
FRED is then used for data cleanup, analysis and pushing to storage, either 3rd party storage services or Data-Base products such as the increasingly popular InfluxDB which has been designed for real time and IoT focused applications.
One of our UK customers – Industrial IoT – has been using FRED to monitor and alert. They have an excellent blog post that describes some of their work on monitoring the full end-to-end system. A diagram from that post is shown below (courtesy Industrial IoT)
In this use case, the popular MultiTec gateway (Conduit) is used. One of it’s key advantages is that it hosts Node-RED in the gateway thus allowing rapid development. Communication between the gateway device and the FRED cloud service can use a variety of protocols, with many customers choosing MQTT for it’s performance and throughput. STS offers a hosted MQTT server as part of the FRED platform supporting tight integration and offering the support and SLAs needed for industrial deployment. In addition, by using the STS Fred nodes on the gateway, direct connections to the flows running in the cloud is facilitated.
Monitoring on behalf of multiple customers
A second customer has a similar setup, but wants to offer monitoring directly to their customers. An approach supported by STS is to use a master FRED account to handle incoming MQTT data from a number of different customers. The master account handles data inputs, cleanup and any real-time alerting. Additionally, data can be archived to InfluxDB for historical charting and analysis.
The master account then passes data to a set of customer-specific accounts, each account pre-configured with a dashboard that allows them to access their data in real-time and, if required, configure their own flows for alerting, integration, or analysis.
This architecture is flexible. Customer flows handle any specific customer data messages, generate customer specific dashboards and allow for flexible alerting via SMS, push notifications, Twitter, etc. In addition, customer flows can subscribe to data directly from MQTT, or use InfluxDB as a real time data store. By archiving all data to InfluxDB, historical charting and ‘offline’ data analytics are supported.
This approach is being used by several customers, some are managing both their master account and all of the customer accounts, in essence syndicating those accounts to their own customers. The advantage of this approach is that their customers do not need to deal with Node-RED and simply use the FRED service as a dashboard. Others set up a master account and then work with their customers to help them setup their own accounts and create their own flows. This approach works best when customers are interested and capable of managing their own flows and wish to tweak or add to the flows and dashboards. Of course, a mix of the two is possible.
If you are interested in knowing more about these capabilities please contact us at firstname.lastname@example.org