Software Toolbox Technical Blog

The adoption of OPC UA technology continues to grow more with each passing year.  And for good reason.  OPC UA provides a means to encrypt data as it is transferred between client and server that other client interface options simply do not. But when it comes time to have that discussion with your IT department around whether they are going to let you run OPC UA inside the firewall on a network, they likely will have concerns centered around common IT concerns in networks. 

Continuing our Tech Support Corner blog series, this post covers some common concerns that our support engineers have encountered from process engineers collaborating with their IT department about OPC UA client's and servers running on their network and the factors to consider in those discussions. 

As you may already be aware, the Cogent DataHub has a wide range of flexible connectivity options between different data sources such as MQTT, OPC UA, OPC DA, ODBC, DDE and so much more.  MQTT client and broker functionality in particular allow DataHub to integrate MQTT data sources with HMI, SCADA, MES, historian and other systems that don't natively support MQTT.

In this next installment of our Cogent DataHub Virtual Training series, we will cover step-by-step how to easily connect 3rd party MQTT clients to the DataHub MQTT broker and convert their data for access by your own systems with OPC UA or OPC DA client capabilities.

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.