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.
Since its introduction in the mid-2000s, the OPC Unified Architecture standard (OPC UA) has quickly shown why it is such a robust and complete successor to the original OPC Data Access (OPC DA) standard. With the growing Industry 4.0 “smart factory” trend (and the adoption thereof), the numerous benefits of switching to OPC UA capable solutions are becoming clearer and clearer. And while I could write volumes about why OPC UA is so great that is going to have to be a topic for another day.
Instead, I would like to focus on one specific enhancement that OPC UA brings to the table and the impact this has on traditional data logging; that is the ability to buffer data.
The OPC UA buffering mechanism was primarily designed for two scenarios:
- Connection loss – Just like most buffers, the designers of the OPC UA standard wanted to facilitate server side data buffering should the connection between the client and server be lost.
- Obviously, if the OPC UA server-side computer were to go down, you would need some level of redundancy in place to account for that to have a true lossless situation –
. - With traditional OPC DA, the data from the device would simply be lost if the client-server connection is broken, as OPC DA servers don’t buffer any data. With OPC DA, if the callback to the client for data updates fails, the server moves on to the next callback it needs to make for that client or another one.
- When using protocols like DNP to talk to devices that buffer data in the field, the loss from a dropped OPC DA connection could be even larger.
- However, with OPC UA, methods exist for the connection between the OPC UA client and OPC UA Server to be re-established using the original OPC UA Session (i.e. connection). (
.) Once resumed, all data that was buffered during the connection loss will be provided to the UA client and polling will continue normally.
- Obviously, if the OPC UA server-side computer were to go down, you would need some level of redundancy in place to account for that to have a true lossless situation –
- Bandwidth optimization – With OPC DA, the rate at which data could be read from the field device (be it a PLC, RTU, network switch, etc.) is impacted by any limitations the OPC DA client software sets on how fast it can receive data and, similarly, limitations the OPC DA server sets on how fast it can send data to the client.
- For instance, reading data from your ControlLogix every 50 milliseconds would not serve much of a purpose if the client consuming the data can only process and update every 500 milliseconds.
- With the OPC UA buffering mechanism, the sample rate at which the OPC UA Server scans the field device is now uncoupled from the rate at which that data is served to the client software.
- Using the same example from above, scanning a device every 50 milliseconds simply means that every 500 milliseconds the OPC UA Server is serving 10 buffered data values to the OPC UA client, your data logging application, to process.
- For instance, reading data from your ControlLogix every 50 milliseconds would not serve much of a purpose if the client consuming the data can only process and update every 500 milliseconds.
Regardless of why your OPC server is buffering data, what happens to that data when the server sends it to your OPC DA or UA client data logger software? If you’re using OPC DA, the answer is pretty straightforward - the OPC DA Server won’t send it at all, since it will never have been queued in the first place.
But, even if you are using OPC UA servers and clients, there is a real possibility that your OPC UA client data logger is discarding the majority of the data. In my testing of various OPC UA Clients out there, most did simply dispose of all but the last value in any data packet in which buffered data was sent. For example, this could mean that, of the last 50 temperature measurements for your furnace, only a single record was recorded – at a 15 minute sample rate you just lost over 3 hours of temperature data and might have a very expensive problem on your hands.
As of version 3.6.0.6, the Software Toolbox 
is able to process queued OPC UA data in cases where the sample rate of the OPC UA server is faster than the rate at which it is being provided to the OPC UA client data logger. Once the OPC Data Logger receives the data, it can be logged to any number of text-based storages (txt or csv) and/or databases (including SQL, MySQL, Oracle, and Access).
We also are continuing to work on innovative ways for OPC Data Logger to benefit from the OPC UA Session management options now that more UA servers are being implemented that support buffering. 
so you’ll know when we add more features in this area.
So does your data logger support OPC UA? What does it do when your OPC UA server sends it queued data? If you don’t know, I would recommend asking the vendor – the business impact is too high not to. If you don’t like the answer, please 
for more information on the and how it can meet your logging needs.
