Software Toolbox Technical Blog

Access to various industrial data via RESTful web services is increasingly becoming necessary in this era of inter-connectivity and big data. From sources such as devices with self-hosted web services to relevant market data such as weather information and pricing for commodities and energy, there is a host of relevant data to be integrated from such RESTful web services.

In this video training blog post, we will cover step-by-step how to easily connect to and consume data from RESTful web services and then push that data to OPC and SQL systems with the OPC Router.

Cogent DataHub is always expanding its wide range of flexible connectivity options between different data sources such as MQTT, OPC UA, OPC DA, ODBC, DDE and so much more.  With the advent of IIoT and its increasing adoption across industries, connectivity to various traditionally non-IIOT data sources via MQTT is key.

If you're not familiar with the concept of a virtual or digital twin, it's the idea of virtual modeling a physical asset or system.  Ultimately, the key motivators for creating digital twins is having the ability to accurately model and predict what will happen with the real-world physical equivalent of that digital twin.  Digital twins are extremely beneficial towards predictive analytics used for pro-active maintenance and process optimization across industries.

In this next installment of our Cogent DataHub Virtual Training series, we will cover step-by-step how to easily connect and push data from OPC data sources to digital twins in the Azure IoT Hub including how to optionally do so through a network DMZ (DeMilitarized Zone) using an additional DataHub as a proxy server for even greater security.

Cogent DataHub enables a wide range of flexible connectivity options between interfaces for different data sources such as OPC UA, MQTT, OPC DA, ODBC, DDE and so much more.  This is why we commonly refer to DataHub as a "gateway", as it is frequently utilized for data integration by external software such as HMI, SCADA, MES, historians and other client applications, including for IIoT integration.

In Part 1 of our Cogent DataHub Virtual Training series, we will cover step-by-step how to easily connect OPC UA (Data Access Profile) client applications to your OPC DA Classic server data sources.

As we discussed in the first post of this series, the term "OPC client" often refers to off-the-shelf HMI or SCADA applications.  OPC clients can also be other custom developed software applications in your enterprise that could benefit from access to OPC process data.  Or there might be a new custom application you need to develop that requires access to OPC process data.  In those situations, you need a reliable, straightforward method to enable those applications as OPC clients.

In Part 2 of our series on How to Develop Custom OPC Clients, we will cover step-by-step how to use low-code techniques to read, write and subscribe to OPC process data through building a basic OPC client application in Visual Studio.NET.

Software-based licensing is a commonality among software solutions across all industries, not just industrial process control.  It's flexible, doesn't require physical shipping and is very reliable. But some system architectures can ultimately benefit from another licensing option - hardware keys.

Hardware key licensing is invaluable for high-availability systems for a number of reasons.  We've recently expanded licensing support in OmniServer, the proven OPC solution for integrating non-standard devices that don't have an off-the-shelf driver, to include optional hardware key support.

In this blog post, we'll cover the key reasons that hardware key licensing is beneficial for many OmniServer users.

When you hear the term "OPC client", you may initially think of off-the-shelf HMI or SCADA applications.  However, it's common in enterprises across most industries for there to be other custom developed software applications that could benefit from access to OPC process data.  Or perhaps there is a new custom application you're working on that needs to access OPC process data.  The question, then, is how to enable those applications as OPC clients.

In Part 1 of our series on How to Develop Custom OPC Clients, we will cover step-by-step how to use no-code techniques to bind production data to various types of user interface elements for reading, or writing, or both to build a basic OPC client application in Visual Studio.NET.

As we discussed in Part 1 of our OPC Router Basic Training series, it is quite common for process industry projects to require logging of industrial process data to a database such as Microsoft SQL.  On the other side of the coin, it is also quite common for information such as recipes or other data to be stored in a database such as SQL and to then need to push that data down to process devices.

In Part 2 of the series, we will cover step-by-step how to write stored SQL data to OPC UA and DA servers based on flexible scripted trigger conditions with the OPC Router.

Logging industrial process data to a database such as Microsoft SQL is a common requirement of many projects across industries.  One of the key applications for storing industrial process data is providing historical context and reporting of the process so that better decisions can be made.

In Part 1 of our OPC Router Basic Training series, we will cover step-by-step how to easily connect to OPC UA and DA data sources to SQL databases for logging process data with the OPC Router.