Mapping of OPC UA data into cumulocity measurements

Dear colleagues,

I want to map and integrate data from an OPC UA Server into a cumulocity measurement object. In the device protocols section I have already created a protocol for this purpose and the UI allows me to create a measurement object for each OPC UA variable. This results in multiple measurement objects with fragments that are only partially set. But my goal is to create only one measurement object with each variable as a fragment. Do you have any ideas to achieve this?

Additionally I found the option to upload a device protocol from a file in the top right corner of the device protocols section. Are there any OPC UA device protocol file templates available? I did not find anything related in the documentation.

I am using Cumulocity IoT Edge version 10.9.0.

Best regards,
Julius

Hi Julius,

you are right. Currently it is not possible to use standard measurements mapping to create measurements with multiple series. Even you define the same type, it will not create one measurement it will create for each variable a measurment object. This behaviour is the result of a specific design. However, there is an option to implement your own logic, it is called “Custom action”. This Custom action functionality allows you to call your own microservice REST endpoint. You are able to retrieve this data and implement your own logic to process this data in your application. In your case you have to combine all series with the same timestamp to one measurement. It is a bit complicated to find the right time (all data retrieved) before you flush the complete measurement to Cumulocity. If you have to wait for a specific time, you have to keep in mind that you will have latency.

Best regards,
Alex

Hi Alexander,

thanks for the response. My current solution is an EPL program that listens for the multiple measurements and combines the values to one measurement object based on the timestamp. But the timestamps of the measurement objects for each series are not the same, so I had to consider some deviation in the comparing of the timestamps. I think this deviation results from the subscribing functionality as there are small delays when the values on the server changes.

Back to your idea. I have seen this custom action method, but I do not understand how the data will be retrieved. In the UI I can select this custom action for each variable and I could create a measurement if I send data with the placeholder ${value} to the cumulocity endpoint. But for each variable I only have the specific value available so I cannot send multiple values at once. So I do not think that I completely understood your idea.

Best regards,
Julius

Hi Julius,

using EPL would be another solution, which is maybe a more elegant way. One hint from my side if you go for this solution. You can configure the processing mode at the protocol as well. If you don’t want to persist the raw data at Cumulocity, only the EPL processed data (in your case the combined measurement).
Please see: OPC UA - Cumulocity IoT Guides
look for processingMode. This fragment can’t be configured via UI you had to use REST api:
POST {{url}}/service/opcua-mgmt-service/device-types/{{deviceTypeId}}

Regarding the timestamp, yes, correct, this can be difficult. Be aware that different timestamps can be available, sourceTimestamp and/or serverTimestamp. I am not sure what timestamp is used for standard mapping. If you have a sensor which publishes a timestamp for all the values to the OPC UA server, maybe you are lucky, that you don’t have this problem if you use source timestamp instead. The serverTimestamp will always the time when you request the data from server. What are you using cycling read or subscription? Also this could make a difference.

Back to custom actions. Yes you are right again. The ${value} will only contain one singel value. This means your implementation has to collect all values before it does something with the complete mesurement. The same logic you have in your EPL program as well, is probably already there.

Be aware that you can use following place holders in your custom action config:

  • ${value}: value of specific node
  • ${serverId}: ID of OPC-UA server
  • ${nodeId}: ID of source node
  • ${deviceId}: ID of source device

the value is a complex string, containing value and timestamps etc.
I am not 100% sure, but it should look like that:

 "serverTimestamp": 132403410091850000,
 "sourceTimestamp": 132403410091850000,
 "value": {
     "value": 381632714
 },
 "statusCode": 0

Best regards,
Alex

Hi Alexander,

thanks for the answer. I think I will go for the EPL solution. Thanks for the hint with the processing mode, I will try this. I am using the subscription mode, so I think the time that is set in the measurement object is the time, when the value on the server changes and the client is informed.

To the second part of my origin question, I saw the option to upload a device protocol from a (json?)-file in the top right corner of the device protocols section. Do you know whether there are any OPC UA device protocol file templates available?

Best regards,
Julius