IoT Bridge for Snowflake

I use Cirrus Link IoT Bridge as the data bridge between our local control layer and cloud services like AWS or Azure. In practice, we collect data from PLCs via traditional protocols such as Modbus and OPC UA in Ignition Edge. Cirrus Link IoT Bridge converts this data to the MQTT standard and publishes it to the broker in the cloud. This allows the corporate headquarters to access data from multiple plants in a centralized and standardized way.

It definitely has a big impact in terms of efficiency and error reduction. Before, we used the traditional polling model, asking for the status of the variable every second, which saturated the network. With Cirrus Link IoT Bridge and MQTT, we use the Report by Exception model. Data is only sent to the cloud if the value of the variable changes. This drastically reduced bandwidth consumption and eliminated bottlenecks in the communication network.

Cirrus Link IoT Bridge has had a great impact on my organization. As I mentioned, there were huge gains before we used the traditional polling model, and now we use the Report by Exception model.

Engineering time savings are the most visible metric after adopting Cirrus Link IoT Bridge. Due to Sparkplug's auto-discovery, we stopped spending dozens of hours manually mapping tag addresses in multiple systems. I estimate that we saved about 40% of the time for commissioning factory data to the cloud. In addition, the reduced network traffic saved the cost of a more robust dedicated link or internet, since exception-based sending uses a fraction of the previous bandwidth.

The native implementation of the Sparkplug B specification in Cirrus Link IoT Bridge offers the best features. This enabled the auto-discovery feature. When we connect a new PLC or create a new tag at the edge, the cloud automatically discovers this new data structure while preserving all the context: name, type, and folder. Another fantastic feature is the native Store and Forward, which stores data locally if the internet goes down and automatically sends it when the connection is reestablished.

It had a positive impact. Before, we needed to generate CSVs and documentation of new tags and go through the whole manual process to send it somewhere. Today, with Cirrus Link IoT Bridge, it automatically discovers what has changed and it can be added there and easily selected by the team.

I think the failure diagnostics in the Ignition gateway could be improved in Cirrus Link IoT Bridge. When Cirrus Link IoT Bridge loses connection or when there is some SSL/TLS security certificate error, the interface does not make the root cause very clear on the main screen. The engineer needs to dig into the system logs and figure out whether it was a blocked network port, a credential issue, or broker instability.

I have been using Cirrus Link IoT Bridge for approximately one year, mainly since we started expanding Ignition architectures to the cloud.

Cirrus Link IoT Bridge is extremely stable, being a very mature module in the Inductive Automation ecosystem. It runs as a service with no memory leaks or crashes.

The scalability of Cirrus Link IoT Bridge is excellent. Since it works by exception—Report by Exception—you can scale to thousands or hundreds of thousands of tags without bringing the server down. It is a solution architected specifically for industrial IoT scalability.

Support for Cirrus Link IoT Bridge is high-level, but I especially highlight the Inductive Automation community forum, the online manuals, and the Inductive University training. Almost any technical question about Cirrus Link IoT Bridge is already well documented.

Before, we used database-to-database connections or tried to pull OPC UA data remotely via VPNs. The problem is that the OPC UA protocol was not designed to handle high-latency networks or frequent internet outages very well, which generated gaps in the corporate data history.

Engineering time savings are the most visible metric, as I mentioned. Due to Sparkplug's auto-discovery, we stopped spending dozens of hours manually mapping tag addresses in multiple systems, and I estimate we saved about 40% of the time for commissioning factory data to the cloud. In addition, the reduction in network traffic saved costs on more robust dedicated internet links, since exception-based sending uses a fraction of the previous bandwidth.

I do not know about the pricing, setup costs, and licensing for Cirrus Link IoT Bridge. Since I work directly in technical engineering and implementation, I do not participate in commercial negotiations, so I am not in a position to speak about the exact licensing costs of the module.

I evaluated other options before choosing Cirrus Link IoT Bridge. We evaluated developing custom Python scripts to package the data in JSON and send it to REST APIs or generic MQTT brokers, such as Mosquitto. We discarded these options because we would have had to code from scratch the critical functions of buffering, Store and Forward, and security—things that Cirrus Link IoT Bridge already delivers ready-made and certified.

Cirrus Link IoT Bridge perfectly solves the OT/IT convergence problem, which is one of the biggest automation challenges today. The integration with Ignition is perfect and the Sparkplug concept is revolutionary. The only points preventing a perfect rating are the initial learning curve and the lack of more user-friendly diagnostic dashboards for network troubleshooting.

Circus Link IoT Bridge architecture in my organization is hybrid. Cirrus Link IoT Bridge module runs locally inside the Ignition server at the plant or on Ignition Edge, but its main function is to publish and receive data from an MQTT broker that is hosted in a corporate public cloud.

I use Azure to host the broker for Cirrus Link IoT Bridge.

I did not acquire Cirrus Link IoT Bridge through the AWS Marketplace.

I recommend Cirrus Link IoT Bridge if you want something that is easy to install and that you can also integrate with other systems; it would be a good choice.

I rate Cirrus Link IoT Bridge a nine out of ten.