Software Toolbox Technical Blog

AVEVA™ users already have a wide range of connectivity options for interfacing with different systems. For many years, OmniServer has been expanding that connectivity to include non-standard, non-PLC type devices that don't have an existing off-the-shelf communications driver. Users of AVEVA System Platform have traditionally connected to OmniServer via either the native SuiteLink interface or OPC DA Classic. AVEVA's OI Gateway provides those users the additional option of connecting to OPC UA data sources, for easier and more secure remote connections to such data sources.

In this blog post, we will cover the basic steps to connect AVEVA System Platform to OmniServer via OPC UA, expanding non-standard device connectivity options for AVEVA users.

AVEVA™ users already have a wide range of connectivity options for interfacing with different systems. Cogent DataHub® also supports an extensive selection of connectivity to different systems that users sometimes need to access from AVEVA System Platform. Users of AVEVA System Platform have traditionally connected to DataHub via OPC DA Classic. AVEVA's OI Gateway provides those users the additional option of connecting to OPC UA data sources, for easier and more secure remote connections to such data sources.

In this blog post, we will cover the basic steps to connect AVEVA System Platform to Cogent DataHub via OPC UA, expanding connectivity options for AVEVA users.

Ongoing digital transformation and operational visibility initiatives continue to demand the integration of different systems using different technologies. With increased adoption of secure OPC UA and MQTT Sparkplug B, it’s only to be expected that users will have systems that support one or the other technology but need to communicate with each other.

Although OPC UA supports a publish-subscribe mechanism with OPC UA PubSub, and adoption of OPC UA is strong and growing, the reality is there will be situations where the user is already using MQTT Sparkplug B and needs to integrate it with OPC UA or vice-versa, without writing custom code or going through complex configuration.

Software Toolbox was founded 26 years ago on the principal of making data and device integration easy by using configurable off-the-shelf software to avoiding writing custom solutions and knowing the pros and cons of and ins and outs of many technologies. That mission remains strong, as you’ll see, as we discuss interoperating between OPC UA and MQTT in this blog post.

If you use OPC UA, you are likely at least somewhat familiar with OPC UA certificates. OPC UA client and server applications typically have Application Instance Certificates to provide application-level security. They are used for establishing a secure connection using Asymmetric Cryptography.

OPC UA certificates include a digital signature by the generator of the certificate. This digital signature can be self-signed or can be signed by a Certificate Authority (CA). Both types of certificates provide the same level of security and can be used in Asymmetric Cryptography. The major difference between CA signed and self-signed certificates in an OPC UA installation is the effort required to deploy and maintain the certificates. The choice of when to use a CA issued certificate versus a self-signed certificate depends on the installation and site requirements.

Many of our products leverage the OPC UA Configuration tool from the OPC Foundation to create and trust certificates and certificate authorities (CA). This tool actually installs with our OPC Data Client toolkit but is also available from the OPC Foundation. But how do we navigate this tool and the use of OPC UA certificates as a whole?

In this blog post, we will cover both methods of UA certificate signing, as well as the tool mentioned above for easily managing UA certificates for your OPC UA applications.

Are you an AVEVA™ System Platform user but you also have some other client or system (HMI, SCADA, other) and need that system to access data from System Platform?  It's a use case that sometimes occurs if your company is acquired another company and a non-AVEVA HMI/SCADA came as part of the assets.  Or perhaps your company merged with another and now your AVEVA system is expected to integrate with other systems.  Your options for sharing data largely depend on what software interfaces these "other systems" support.

In this blog post, I'll discuss how to share your AVEVA System Platform 2020 (or newer) data via OPC UA (without using OI Gateway) using the TOP Server OPC UA Client driver for situations where you have another non-OPC UA capable client application that needs access to process data in your AVEVA system.

A common use case that we encounter with many AVEVA™ users is the need to share data from System Platform with some other client or system (HMI, SCADA, other). It's not uncommon for a company to be acquired by another company and its assets and a non-AVEVA HMI/SCADA came as part of the assets.  Or perhaps a system is being add with limited interfaces for external connectivity.  Your options for sharing data largely depend on what software interfaces these "other systems" support.

In this blog post, I'll discuss how to share your AVEVA System Platform 2020 (or newer) data via OPC UA (without using OI Gateway) using the OPC Router for situations where you have another non-OPC UA capable client application that needs access to process data in your AVEVA system such as an ERP system, IIoT platform, web service and more.

If you’re reading this post, you’ve almost certainly at least heard of DCOM. And, possibly, you’re one of many who have struggled over the years with the trials of configuring remote OPC Classic connections between machines where DCOM inevitably increased your time and difficulty for what should be a relatively painless task.

And with the latest Microsoft hardening for DCOM authentication, configuring DCOM for the many existing OPC Classic solutions out there isn’t getting any easier. This blog post discusses alternatives to DCOM that cover a range of use cases depending on what software you already have installed and your existing system architecture.

Are you or have you ever been in a situation where you were working with both an AVEVA™ solution and some other client or system (HMI, SCADA, other) and needed to share data?  Perhaps your company acquired another company and its assets and a non-AVEVA HMI/SCADA came as part of the assets.  Or perhaps your company merged with another and now your AVEVA system is expected to integrate with other systems.  Your options for sharing data largely depend on what software interfaces these "other systems" support.

In this blog post, I'll discuss how to share your AVEVA System Platform 2020 (or newer) data via OPC UA (without using OI Gateway) using the Cogent DataHub® for situations where you have another non-OPC UA capable client application that needs access to process data in your AVEVA system.