2020 was an extraordinarily challenging year for the world and, as a result, a phenomenally transformational year in manufacturing as industries worldwide had to adapt to succeed in the face of new challenges.
We start each year off, in the spirit of a new year, with sharing references to learning resources that users have told us were the most helpful to them over the course of the last year. This year's post contains an extraordinary amount of virtual technical training opportunities.
So far in our ongoing Exploring OPC UA blog series, we have taken a primarily general look at OPC UA Certificates and how they are used by OPC UA clients and OPC UA servers to keep industrial data secure.
In this third post of the series, we'll take a step back and look at OPC UA security in general with respect to the layered approach that is employed to cover aspects such as authentication, confidentiality and the integrity of communications.
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.
