XTCE12 — Need support for mask alarm

A mask alarm applies to numerics and enums – although usage in floats is discouraged. It defines 16-states which map 1 to 1 with values (say 1-16), it's a 16-bit mask – each bit is either a care or don't care. If set to 1, it's a care bit. If the value associated with that bit appears, it is in alarm. If the mask bit is set to 0, it's a don't care bit – and the value associated with it will not trip an alarm. When used with enums it's almost like an enum alarm list,except the states can go "past" the range of values given in the enum list itself. For example, suppose an enum had the values of OPEN=1, SHUT=2. The mask could be 0xfffffffc - as one and two are allowed and valid. And any other value would be in alarm. Because there's only two enum values and each of these is green but any other value is read, it is hard to completely simulate this alarm with the enum alarm list. It's possible to use a condition perhaps in this one example but the current syntax requires the enum alarm list. Further transferring this information through to another party will be hard in that case. Reported by JPL.

Mask alarm capability exists but is not as clean as it could be

It is possible to define mask alarms with the latest improvements in the XTCE 1.2 proposal. As a result, we propose to defer this request. It is deferred instead of closed because there is a possibility that this could be implemented. It would impact other comparisons, so for now it is chosen not to do that.

For the case of enumerations, the implementer should be aware that any undefined enumeration is an alarm of sorts. This is implementation specific. The capability now to define ranges in enumerations also help define explicit out-of-bounds alarms if needed.