In the first post of our ongoing Exploring OPC UA blog series, we covered the three functions that OPC UA Certificates (also known as Application Certificates) serve in the context of OPC UA security.
In this second post, we'll take a look at what happens to messages after you have trusted the application certificates and have enabled security on the OPC UA endpoint. Specifically, what does Sign&Encrypt mean on an endpoint and how can we be sure that the data is truly secure.
The use of certificates in cryptographic applications and online communication protocols is nothing new and can practically be traced all the way back to the 1970's when the "framework" for public key encryption (more on this in a future blog) came into being. With the (now-not-so-recent) Industry 4.0 movement coming out of Europe, and the design and operation changes brought about by the IIoT phenomenon, we are seeing more and more systems – that have traditionally been air-gapped and kept offline – being brought online to take advantage of the digital revolution in which we find ourselves.
Despite how you feel about this (r)evolution there are several exciting changes that are being brought about, including the one I want to discuss is the increased adoption of OPC Unified Architecture (OPC UA) in automation systems.
In this first post in our ongoing Exploring OPC UA blog series, we will look at what OPC UA Certificates are and what they provide and subsequent posts will further explore how they are used in OPC UA, how they fit into the security ‘stack’ of OPC UA and will then look at how OPC UA Certificates are utilized and managed in several Software Toolbox applications. First thing’s first however; what are OPC UA Certificates and what are they used for?
In case you're not familiar with OmniServer, it is a user-configurable I/O server solution that you can configure through a user-friendly interface to communicate with various devices that do not already have off-the-shelf drivers written for them.
A question that our support engineers at Software Toolbox sometimes receive from both new and veteran OmniServer users alike is whether an item in the OmniServer sequence builder, which is used to build the send and/or receive message for a device protocol, requires a formatting code or not.
Continuing our Tech Support Corner blog series, this blog post covers under what situations a formatting code is required for an item defined in the OmniServer sequence builder of a protocol and when a code isn't required.
If you're familiar with the term high availability, then you're also more than likely at least aware of virtualization environments such as VMWare and Hyper-V. As computer hardware specifications have grown exponentially over the years, virtualization is more and more becoming the norm for hosting of automation control systems.
A common question that our support engineers at Software Toolbox receive from new and veteran TOP Server for Wonderware users alike is whether TOP Server supports virtual environments, which ones and what are the best practices.
Continuing our Tech Support Corner blog series, this blog post covers best practices with respect to using TOP Server for Wonderware in virtualization environments such as VMWare and Hyper-V.
As you are probably aware, the Ping command is one of the most widely used diagnostics tool when troubleshooting communication issues on Ethernet networks. I would accredit this popularity to the fact that everyone knows how to use the command, it's extremely simple to execute, and the results are not really open to interpretation (i.e. it either works or it doesn’t); or are they?
When troubleshooting communication issues, the most common line we hear when something isn’t working is “but I can ping it” as if this alone should serve as definitive proof that everything is working as expected and the communications server is choosing to not communicate.
Continuing our Tech Support Corner blog series, this blog post covers some common misconceptions about the Ping command, particularly how it can be used efficiently, and when it may not be the best tool for the task, as well as, better alternatives to Ping that actually provide actionable data.
You may or may not be aware that our technical support team at Software Toolbox maintains, updates and adds new content to an extensive knowledge base built from answers to all of your questions from over the years. We like to frequently review which of our knowledge base articles have been used the most to see what users like you need help with and what is most relevant.
Continuing our Tech Support Corner blog series, this blog post covers the why's and how's of using the popular and powerful network analysis tool called Wireshark as an additional tool in your troubleshooting arsenal.
With the wide range of devices that use Modbus for their communication protocol, you'll find many different interpretations, terminology and labels with respect to how to access different types of data in those devices. Sometimes a device manual might only refer to the supported Modbus function codes and the range of offsets available for those function codes.
In this blog post, I will step through the specifics of Modbus function codes and how they pertain to addressing, and how they affect what addresses to use in TOP Server for Wonderware applications.
I'm sure you've all at least had some interaction with Modbus, working in the automation industry. It's one of the most widely used protocols (if not the most widely used) in the world. Which is both its blessing and its curse, to some extent.
Given how long Modbus has been around and in use as an "open" protocol (starting in 1979), there have been many different interpretations of Modbus throughout the years. And with those different Modbus interpretations, much confusion about the different terminology for accessing data.
In this blog post, I will step through the basics of Modbus addressing including how offsets come into play, and how they affect what addresses to use in TOP Server for AVEVA applications.
