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 Wonderware applications.
What is the most important feature for any data logger to have? At the end of the day, we are trusting a data logger to take our data and store it. Now whether that is for reporting, optimization, legal reasons, or simply to retain process data over some period of time in case it might be needed later, we expect the data to be logged without any losses.
This is particularly true in the industrial automation space, where the amount of data that is being logged is growing almost as exponentially as the speed at which the data is needed in order to have a business impact. As such, the prospect of losing data can very quickly result in lost jobs, thousands of dollars in lost production, and legal or financial penalties in case of an audit.
So how much do you trust your data logger to really be logging 100% of the data that it should be? In this blog post, I will address these concerns and highlight the ways OPC UA provides capabilities that software applications can leverage to provide peace of mind.
Our 
is designed to help professionals that are new to the industrial automation space whether at the start of their careers, or moving into the operations technology (OT) world from an IT or other background.
One of the common challenges in Industrial Integration is communications between different brands or manufacturers’ control devices (PLC, DCS, Drives, RTUs, smart sensors). While most control devices have methods of communication, and some industry standards have helped, they don’t all communicate using the same methods or protocols, and even if they both have the same serial or Ethernet wiring the difference in communication protocols prevents them from passing information. It’s the same problem you have if someone calls you on the phone, but doesn’t speak the same language.
While, as humans, we may be able to overcome a difference in dialect, machine communication has to be precise and exact. Small differences in addressing or data formatting can be enough variation to create communications failure. So how do people overcome this challenge?
In this edition of OPC Talk with Win and Marc, we’re going to address some common questions we get about redundancy involving OPC software. If you’re new to the industrial automation space and want to learn more about redundancy in automation in general, visit our Demystifying Redundancy in Automation blog post.
We’ve been working with the OPC software interoperability standards since 1996, and it’s easy to forget that others who are new to this space often find the whole discussion around the OPC standard and all the different standards confusing.
