Software Toolbox Technical Blog

In the ever-growing digital landscape of manufacturing operations, single use solutions & applications may solve issues, but also create their own data silos. These silos present multiple challenges (limited visibility, slower decision-making, security blind spots) and lead to missed opportunities due to the complex management of varying solutions. For example, OPC HDA is a standard utilized for collecting and sharing historical data across industrial automation technology solutions. Based on the standards of OPC DA, integration challenges arise due to the dependency of COM and remote DCOM connections, creating incompatibility with newer solutions and technologies.

Today we'll explore how Cogent DataHub was used to solve many of these integration headaches and silos by providing a middleware platform for connectivity between a variety of protocols and technologies. With the latest major revision of Cogent DataHub V11, the ability to collect historical OPC HDA data is now possible with the addition of the OPC HDA Client capability.

Your organization has a custom developed application that performs important tasks, and you need to provide access to that software from an HMI, SCADA, Historian, MES, or other system acting as an OPC UA Client. Adding an OPC UA server interface to a custom application that either you've developed or that you've taken over from someone else can be a daunting task. This is especially true if you're unfamiliar with the low-level details of the OPC UA specification.

Accelerate OPC UA Server Development with the OPC Wizard Toolkit

The OPC Wizard UA Server Development Toolkit addresses this reality head-on by providing a rapid development framework that handles the underlying OPC UA nuts and bolts for you. In a recent webinar we covered how to add an OPC UA Server interface to a custom .NET software application using OPC Wizard, without having to become an “OPC wizard” yourself.

Rather than spending hours on end diving into the specifications and debugging protocol details, you can utilize simple read, write, and subscribe methods, resulting in less engineering time and faster ROI.

As technical consultants at Software Toolbox, we are often approached by users who need to expose data from a software application they have written, or are writing, to communicate from systems they own to a client, HMI/SCADA, or historian. And, in many cases, there are dozens of applications at different sites that the data needs to reach. The question we are then presented with is, “how can I accomplish this quickly and efficiently while staying within budget?” 

Our hope is to answer this question and share from our experience with OPC since 1996, what our users have told us are the common reasons why they chose to use a commercial OPC server toolkit, and to help readers determine what factors to consider for their specific situation and circumstances.

In a previous blog post, we covered the basics of commercial OPC client development toolkits, with a dive into the benefits of using one, while here in part 2, our focus is on OPC server development toolkits. If you read our blog on OPC client toolkits, you will likely notice a clear overlap in the benefits you gain from using both types of commercial OPC toolkits.

When your industrial operations depend on continuous OPC UA client-server communication, even short disruptions can ripple into major consequences. OPC UA session timeouts act as a built-in heartbeat, ensuring clients and servers know if communication has stalled so resources aren’t wasted on dead connections.

But here’s the catch: poorly tuned OPC UA timeouts can trigger needless disconnects, looping reconnections, or hide real failures that delay recovery. In critical industrial automation environments, a few minutes of uncertainty can mean lost production, safety risks, or compliance issues.

In this blog, we’ll show you why OPC UA timeouts are worth your attention, and how the right practices and tools can save you from downtime, data gaps, and unnecessary headaches.

Sometimes we are approached by users and integrators with very specific business demands, and an off-the-shelf OPC client solution isn't always the answer to their problems. As they explore the fully customizable development toolkits on the market, they are often concerned that their OPC expertise is inadequate for writing their own OPC client application. How should states and client objects be handled? When would an OPC group need to be created and have items added? What about timeouts, keep-alive intervals and more? Isn't PubSub (as in OPC UA PubSub) a deli sandwich from a popular grocery store called Publix in the US region we live in? Look – we hear you – and its problems like this that Software Toolbox has been solving since 1996. Let's start by saying this up front – you do NOT need to be an OPC expert or understand the internal complexities of OPC connectivity. Our OPC client development toolkit handles all of that and so much more for you. Let's learn more. 

JSON (JavaScript Object Notation) is a file format that has become fairly common in the industrial automation industry for storing data or information (including such things as configuration files). But also as one of the most common data formats used by RESTful APIs and web services, which are commonly used for providing a range of useful information including energy prices and weather data.

Sometimes, of course, depending on the application, some or all components of JSON packet might be variable or dynamic in nature, which can make it difficult for off-the-shelf industrial software solutions to properly parse the information from those packets.

In this post, I will cover step-by-step how to leverage the scripting capabilities of the OPC Router to access and parse JSON packets either from a JSON file saved to a specific file directory or from a RESTful web service after which that data can be used with any of the other connectors that OPC Router supports. For this example, we log the data to a SQL database.

A common misconception about TOP Server as an OPC server is that TOP Server will poll your device/devices automatically with no OPC client connected. So, when you are getting started with TOP Server, it is good to have an accurate understanding of how interactions occur between each node of a basic OPC architecture— client-server and server-device— to ensure that the configuration meets your needs and can be scalable to more demanding projects.

Continuing our Tech Support Corner blog series, in this blog post, we will discuss some basics of the interactions between an OPC client and server, including different types of reads and the expected behavior that you'll see as a result of those interactions.

If you're a TOP Server user with OPC UA client connections to TOP Server, you may have noticed a section in the OPC UA Configuration Manager titled "Discovery Servers". Possibly you're using an OPC UA Local Discovery Server (LDS) but many of our users aren't sure what an LDS is, how to use one with TOP Server or why they should.

Continuing our Tech Support Corner blog series, in this blog post, I will step through how to make TOP Server discoverable via a Local Discovery Server using the OPC UA Configuration Manager, as well as what this does behind the scenes so that you can make other OPC UA servers discoverable even if they don’t have a similar built-in configuration tool.