User defined status code for time series

@Glen Sykes? 

Hi Olav, thanks for the enquiry!

For the purposes of interoperability with OT systems, we strictly follow the OPC UA standard, which unfortunately means we cannot implement a status code in the way you ask without breaking our interoperability.

As I understand it, there is scope within the standard for a user defined value to be included in the status code, using bit position 29 (though the wording in the standard make it a bit difficult to comprehend).  I’m not sure if this is useful to you, or whether it’s best to continue using the GoodEntryReplaced option.

https://reference.opcfoundation.org/Core/Part4/v104/docs/7.34

 

Hi! I am working on the time series team in Cognite.

I am curious. Why would you want Replaced to be it’s own main status code instead of using GoodEntryReplaced?

Thanks for your reply @Sigurd Holsen and ​​​​​@Glen Sykes. We understand that you need to follow the OPC UA standard, so we are OK with not doing any customization. 

I’ve seen a few demos related to status flags given by you Glen. I remember that you mentioned the Reserved Filed (bit position 29). It was this one I was a bit currious about when I asked this question. 

Background for my question: 

We have a state estimator that are producing data with a lot of status codes. We are simplifying these codes and end up with three main codes: Good, Replaced and Uncertain. Except for Replaced, that is a good fit with the main status codes availble within CDF (Good, Uncertain and Bad). We know that GoodEntryReplaced is an available sub status code, but our impression is that you cannot get that much built in fucntionality related to the sub status codes.

We are using the Cognite Python SDK and we see that the main status codes are supported under aggregates. For example “count_good” is an aggregate you can pass in to the Datapoints.retrieve function. We cannot see that the sub status codes are supported the same way. 

We are still exploring this, so we will probably learn a lot during the comming weeks.

OK I see.  You want to be able to use the API filtering and aggregations against this specific sub-code.  We chose not to implement aggregations on sub-codes due to the number of them and the cost (both in terms of effort and computational).

I’ll speak with the team to see if there’s a way we can help you here, and look at other customer feedback for anything similar and come back to you.