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 (curtesy 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 customer premises. The Master account handles data reception, cleanup and any real-time alerting. Additionally data is archived to InfluxDB for historical charting and analysis.
The Master account then passes data to a set of slave account, 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 purposes.
This architecture is flexible. Customer flows handle any specific customer data massage, generate customer specific dashboards and allow for flexible alerting via outputs such as SMS, push notifications, Twitter etc. In addition, customer flows can take data directly from MQTT if latency is an issue, or use InfluxDB as a real time data store. By archiving all data to InfluxDB, historical charting and ‘offline’ data analytics is supported.
This approach is being used by several customers, some are managing both their Master account, and all the slave accounts, on behalf of their customers – in essence syndicating those accounts to their own customers. The advantage of this approach is that their customers do not have 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 their 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 this capability please contact us at email@example.com