Software Toolbox Technical Blog

IoT, IIoT, MQTT, Connectivity of Things, Big Data, The Cloud - by now, you've heard these terms in some way, shape or form.  Perhaps you're working on a project requiring you to push and/or pull important process or business data to/from a cloud solution. Big data analytics applications ranging from predictive maintenance to "smart" manufacturing, amongst many other use cases, are becoming more and more common.

And Google© is a household name both in the private and professional world. Chances are, you got here using Google – whether through a Google search, or by using Google Chrome (or both). But did you know that Google has their own cloud solution called Google Cloud IoT Core©? Amongst many other things, Google Cloud IoT Core acts as an MQTT broker for storing and sharing important data in a secure cloud along with artificial intelligence and analytics and many other IoT services.

But how do you go from your data sources to Google Cloud IoT Core? In this second post in a series about connecting DataHub to IoT solutions (if you missed our first post on connecting to Amazon AWS IOT Core©, click here), we'll step through how you can configure Google Cloud IoT Core and connect it to your process and business data sources using the Cogent DataHub IoT Gateway©.

IoT, IIoT, MQTT, Connectivity of Things, Big Data, The Cloud - I'm sure you've at least heard these terms in the course of your day (whether in the scope of your job or in an advertisement during a football game you happen to be watching).  Maybe you're even working on a project requiring you to push and/or pull important process or business data to/from a cloud solution - possibly for big data analytics applications ranging from predictive maintenance to "smart" manufacturing, amongst many other use cases.

And Amazon© - well, I'd wager there isn't a single person out there who doesn't know who Amazon is. But did you know they have their own cloud solution called Amazon IoT Core©? And maybe you didn't also know that Amazon AWS (Amazon Web Services©) IoT Core acts as an MQTT broker for storing and sharing important data in a secure cloud along with artificial intelligence and analytics and many other IoT services.

But how do you go from your data sources to AWS IoT Core? In this post, we'll step through how you can configure "things" in Amazon AWS IoT Core and connect them to your process and business data sources with the Cogent DataHub IoT Gateway©.

Having ready access to the wide array of industrial data available in an enterprise is increasingly important these days, for a variety of reasons.  With ever-expanding applications for using "big data" towards efficiency initiatives such as digital twins, predictive analytics and predictive maintenance, having the ability to bring all of your industrial data together is essential.

In order to analyze that data, however, the upstream systems performing that analysis need access to the actual data - data that is typically widely dispersed geographically and even departmentally within locations.  One interface that is relatively common for such systems is the ability to act as an HTTP (or REST) client.

This blog post will provide an overview of an easy and secure way to share industrial process data available common OPC UA, OPC DA and SQL database sources with big data and other systems that can act as an HTTP / REST Client using the OPC Router. You'll also have a chance to download our free guide with step-by-step instructions.

It can be tricky in this era of increasing cross-connectivity of anything and everything, from a lowly household appliance to IT/OT hybrid systems applying predictive analytics to an industrial process, to balance connectivity everywhere and the required security to mitigate cyber threats.  In the past, remote access to industrial process data often required network access to the actual HMI or SCADA system on the process network.  But why do you need network access to your SCADA system, when all you really need is just to access the data?

In this blog post, we'll discuss a few of the key benefits to having remote access to your industrial process data, which can be essential to making timely business decisions and discuss a flexible solution for enabling remote access without exposing your industrial process network to outside threats, including how to sign up for a free account for a limited time.

With the relatively recent availability of OPC UA server capabilities in Siemens S7-1500 PLCs, access to live production data is now open to third-party applications. As a result, those applications can now communicate with hardware that was formerly locked behind proprietary communication drivers.

The OPC Data Logger's OPC UA client interface allows users to quickly and easily connect to S7-1500 PLC’s and log data to their preferred data storage option without the need for intermediate applications. This blog post covers the high-level steps involved with logging data from an S7-1500 controller and you can then download the free hands-on guide with detailed steps.

In recent years, many of our users have let us know they are adopting the latest Siemens technology, particularly S7-1500 controllers.  And, with that adoption of those controllers, users have been asking for connectivity via the symbolic optimized block addressing.  So we added a Siemens Plus Suite to enable connectivity to new and legacy Siemens devices.

This post focuses specifically on the general steps required to integrate S7-1500 controllers by connecting to their embedded OPC UA server using TOP Server for AVEVA.  

If you’ve been following our blog series on custom error detection, you’ll remember that OmniServer provides a large number of pre-defined Error Detection Codes (EDC) for use in different protocols for non-standard device communication.  And, again, it’s not uncommon to find an EDC from a vendor that is not pre-defined due to some specialized handling by the device manufacturer.

As we covered in our previous posts on creating a custom checksum and LRC, OmniServer gives you the ability to build custom EDCs in an OmniServer protocol to handle these situations.  This post, the final of three on custom Error Detection Codes, covers the basics steps to creating a custom CRC (Cyclic Redundancy Check) in an OmniServer protocol.

You may be aware that OmniServer provides a wide variety of pre-defined Error Detection Codes (EDC, also known as CRC, LRC and Checksums) for use in protocols for non-standard device communication.  However, it’s not uncommon to find an EDC that isn’t pre-defined due to some specialized handling by the device manufacturer.

To handle such situations, OmniServer provides the ability to build your own custom EDCs in an OmniServer protocol.  This post, the second of three on custom Error Detection Codes, will cover the basics of creating a custom LRC (Longitudinal Redundancy Check) in OmniServer.