Add proper handling of OPC UA status (quality) codes

[ralphlange]

The OPC UA status codes are transporting a vast amount of information, a lot more than the EPICS database records can represent.

Here's an idea of how to improve the interface between the EPICS database and the OPC UA quality information, without getting over the top.

• For the data records:
  • Have a configurable mapping between Good/Uncertain/Bad and the EPICS severities. (Reasonable default maybe OK/OK/INVALID or OK/MINOR/INVALID, overwrite through info() structures in the record instance.)
• Provide an API for quality records:
  • Support stringin and longin records, which can be configured as the quality record for an existing OPCUA record. The easiest configuration would be using a different DTYP and have the INP point to the referenced OPCUA record.
  • Have a configurable mapping between Good/Uncertain/Bad and the EPICS severities. (Reasonable default OK/MINOR/INVALID, overwrite through info() structures in the record instance.)
  • Set the stringin value to the status (quality) text, the longin value to the full OPC quality code.

[bkuner]

My experience is that all records from an server become bad if the connection is bad. So it seems to me ok if the record gets invalid if its not able to get the data - means the uncertain is also a kind of bad. If more information is of interest than more sophisticated output should be done to the IOC console as a debug oportunity with TPRO>1 I suppose most users have a big amount of records (Here one RF-Amplifier about 1800 signals!) I think it is not a good idea to spend extra records to each of this. For a common connection problem you don't need it and for single channels you can do console debuging. To improve this debug info is always a good idea.

[ralphlange]

It's not that easy.

E.g., for the WinCC OA server:

• an item that has not been updated, and still has the default value - Uncertain
• an item that is usually the result of an expression, but has been directly written to - Uncertain
• an item that has been manually overridden in the server - Uncertain

In these cases, it totally depends on the application: Uncertain might be good in the context of the value., might be a warning, might be INVALID.

I don't make any assumptions - I just want to provide the possibility to the user to either show the status string (e.g. in a device specialist panel), or to get the numerical value and do some CALCulations to maybe generate a specific alarm if an important value gets overridden.

[bkuner]

I took a short look on the WINCC System. Hm EPICS seems to get old. From the records native status are READ or WRITE the only usefull ones, together with the severities. Is this enough report to get the operators attention? Do we want to build the WINCC functionality around? Much work for what? If you have WINCC why not use it to get the information about the channel you want?

[ralphlange]

In our use case, WinCC is the local control system, EPICS is the supervisory system for visualization, archiving etc. - the classical SCADA case.

For this generic EPICS support, I don't want to make any assumptions on how people use it. I just realize that the OPC UA item status contains complex information, that might be interesting and valuable for the EPICS based supervision layer to know, visualize, archive. To allow this, I would like to have the simplest possible support to get to that information in the most versatile formats: as bitfield and text. Note that all this is purely based on the OPC UA specification, and not related to WinCC that is used in my application.

As for the EPICS alarm status: there is COMM (communication error) which actually should be used when the connection goes down - but that's worth a separate issue.

[ralphlange]

The configurable mapping would save the two extra records that are otherwise necessary if you are not happy with the default mapping of severity: one record to fetch the item status, and one calcout to generate the severity allowing to forward it to the item data record.