I have been studying PMU data quality in order to help to filter results which are displayed to the end-user in Grafana. I have come across with a point tag called FLAG (available on ActiveMeasurements connector) which can be used for such filter but I could not find the meaning of it. Is there any documentation that maps FLAG signal? I suspect it is a composition of STAT signals…
related discussion: OpenPDC Status Flags
Hello Ricardo,
The FLAG signal type refers to the “Status Flags” provided by the upstream PMU, typically used to report on data errors or time errors detected by the device. The meaning of the flags depends on the protocol used to retrieve data from the device. There is a StatusFlag Reference link on the Graph Measurements page of openHistorian Manager that describes what each of the flags should mean for the IEEE protocols.
Thanks,
Stephen
Hi, thanks for the clarification. I understand that the FLAG PointTag as obtained via Grafana (HIS plugin) is a QWORD HEX number which converted in bit will results into 64 digits, which can then be mapped as described above. Is that the case?
That doesn’t sound quite right. I’m not too sure about Grafana data types, but there are only 32 bits in a status flags measurement. Whatever number is being reported to Grafana would need to be operated on as if it’s a 32-bit integer in order to extract the values of the individual bits.
The screenshot I provided only shows the mapping for the IEEE C37.118 protocol which uses the low word of the status flags measurement. There is also a tab for Abstract High Order Bits which provides information about what openPDC puts into the high word of the status flags. The high word provides a common set of flags that is less dependent on the protocol used by the PMU data source.
Yes, indeed is 32bits and now it makes sense, sorry.
This is the mapping I have now, I hope is now correct!
I can’t help but notice all your hex numbers only use decimal digits. Are you sure those are actually hex values? I ask because normally bits 15 and 19 should be in sync, and also bits 13 and 18. That doesn’t appear to be the case in your spreadsheet, and if I interpret all those hex values as decimal values instead, the expected bits do stay in sync.
I’ve realized my mistake in using HEX instead of DEC 
With that fixed, I can now confirm that the sync bits you described are aligned. It looks like we’re in agreement now. See screenshot updated below.
Regarding the ‘reserved for security’ bits I don’t know the exact interpretation. It can vary depending on the specific implementation and context of the PMU, maybe? If you encounter PMUs with these bits set and are unsure how to interpret them, it might be helpful to refer to the PMU’s documentation or contact the manufacturer for clarification? Any guess?
Those bits don’t appear to mean anything, according to the IEEE C37.118-2005 standard. If a PMU sets those flags, it means they are either using a newer version of the standard (such as IEEE C37.118.2-2011) or they have ascribed their own meaning to the flags.
Right, indeed I need to find out more info about these bits with the PMU vendor. I believe we have reached conclusion for the topic. Thanks!!
