Am I doing the right thing using DCAF for my project?

[MichaelWestwood]

Hi All,

I must first say that I'm hugely impressed with DCAF and big thanks to all contributors.

The system I'm working on is used for monitoring the condition of big overland,steel core conveyor belts. It acquires 64 channels of analog readings fomre a magnetic sensor and a few more fomr other sensors and can include a linescan imager. The "processor" embedded win PC acquires and processes all this data and outputs an overall status, alarms, etc, and also detailed info in the form of "events" where an event may be a break in the steel chords, a splice, a hole in the rubber, etc. The number of events is indeterminate. An event is a cluster containing =lots of data including basics like ID, Location, Timestap, etc, and also an array of clusters for multiple measurements, a flattened image, 2D numeric arrays, eg, magnetic image, etc, so it's a little complicated.

I'm building a communication gateway which will get the detailed data from the processor and make it available to plant control and analytics via standard protocols, with the current requirement being Modbus TCP and OPC-UA. What data is available for any protocol will depend on the capability of the protocol.

Currently the prime concerns are:

1) Stability in the field in many systems distributed in remote areas.

2) It must not effect the performance of the engine even if running on the same machine

After a lot of research, thought, and shaking of fists at the clouds, I decided to use DCAF even though my application does not appear to fit the DCAF recommended use cases. My reasoning was :

1) It's better tested and more stable from the word go than anything I write myself.

2) There are existing modules for Modbus and OPC UA

3) It's easily extensible so if other protocols are required in the future minimum cost and effort is required.

4) The knowledge is useful for other projects in the future.

5) It's open source, so a module can be easily be adapted if necessary.

6) No surprise license fees in the future.

Am I doing the right thing? There seem to be so my ways to do things like this in labview. It seems the DCAF engine is similar to the shared variables engine? There is DSC with Modbus as well as several other modbus options, NI stand alone OPC-UA library (at $500 per license). These seem to integrate into a more transparent, browseable data neighbourhood and run at the service level. 

Isn't an OPC server effectively the same as what I'm doing?

Is OPC-UA slow? Years ago I used OPC and one customer is a large steel mill who no longer spec OPC because it gets too slow.

When using OPC in those days it seemed that the shared variable protocol was based on OPC or vice versa, and it worked and is still working

And so on, and so on, and so on...

Any comments on any of this would be gratefully appreciated, thanks in advance.

Mike 

[mtitoo]

If I understood your project correctly, you have to develop an application which takes the detailed data from the processor (embedded Win PC, what type of app?) and send it to plant control system via OPC-UA or Modbus over Ethernet also runs in the same machine. I guess you already know how to communicate with the existing processor application. We had to develop similar application to publish cRIO data into a larger Plant management system (Ignition from https://inductiveautomation.com/) via OPC-UA. At that time, I researched quite a bit about OPC-UA performance and its evolution from OPC-DA which used to be dependent on COM. OPC-UA is a cross platform based architecture and quite fast (still need to understand how fast you need to send the data). But as you mentioned, we had to pay for licensing fee. OPC-UA comes with some impressive features like auto-detect client/serve and tags, logging, historical data etc. but again it all depends on which plant management software your company uses.

Regarding to application, not sure why you're planning to use DCAF. The application should be very straight in my opinion. Read data packets from processor and publish those tags via OPC. Rest should be handled by Plant management OPC Client software which should auto-detect these OPC-UA servers and populate all these tags you added. Am I missing something?

[Jacobson-ni]

A few notes about OPC as I wrote the base of that module. First of all, I want to make sure you are aware of the distinction between OPC UA and OPC DA. The shared variable engine I/O server that you would get from DSC module handles OPC DA communication but not OPC UA. The DSC module does have an API which handles OPC UA communication which was later split into its own toolkit. If you are going to use the OPC UA DCAF module you would need either the module/toolkit installed depending on your LV version (RT systems don't need a deployment license)

Is OPC UA slow? I guess it kind of depends on your definition of slow. Benchmarks for the OPC UA toolkit in 2017 have shown that we can read 10,000 double nodes in ~930 ms intervals on a 9036 (~340ms on a windows 7 computer). Now I haven't benchmarked the OPC UA DCAF module but I would guess that it would be slower based on the fact that I used an earlier version of the API which doesn't do multi-read or multi-write. I did this purposefully so that the module could be used back to LabVIEW 2014 using the DSC module and after 2017 when using the OPC UA Toolkit.

Additionally, if you are mostly reading nodes, both of these read/write APIs might be slower than the subscription method depending on how often the value of the nodes are being updated. Using the subscription method you basically tell the server what nodes you are subscribing to and at what update rate. Then a the update rate interval, you will get a user event with any node values which have been updated during the last sample period. If you were to write your own application this might be something you would want to look. I just didn't use this approach because it doesn't really fit the DCAF methodology.

Finally, if you are going to do Modbus in LabVIEW I always recommend using the Modbus Library on VIPM which is now on GitHub. 

https://github.com/NISystemsEngineering/LabVIEW-Modbus-API

[MichaelWestwood]

Thank you both for your time an effort, your replies have been very useful.

[MichaelWestwood]

I think you're right, my reasoning is:

1) The area where DCAF offers stability and reliabilty is almost trivial in my case

2) Race conditions are a very minor risk, if at all.

3) There's no cost benefit since DCAF modules will require the same licenses for OPC, etc, anyway.