TriggerMethod not used (?)

[zoot-inge]

The DPD (Device Process Data) node holds a TriggerMethod in attribute D. This gives information on when a DDI (attribute B) is logged:
1 = Time interval
2 = Distance interval
4 = Threshold limits
8 = On change
16 = Total

TriggerMethod doesn't seem to be used for ADAPT although this seems important for the scope of a logged value.

[kelly-nelson]

Use of the DPD object within this plugin is somewhat limited due to a couple early implementation choices.

1. Since the WorkingData is scoped to a DeviceElementUse which itself is scoped to an individual OperationData, we define the WorkingData descriptively as the instance of the DLV within the TLG, vs. prescriptively from the DPD.

2. The timelog data has been denormalized to fill a value for all WorkingDatas where the data may be intermittent (see Mappers/LoggedDataMappers/Import/RepresentationValueInterpolator.cs).

I believe we do use the DPD to try to read a name and unit off of proprietary DDIs, but otherwise DPD attributes may not be used in the plugin. If you have a need for this particular attribute, there is a LoggingMethodEnum in the ADAPT framework currently attached to the DataLogTrigger. We could likely reuse this same enum on another of the ADAPT objects, and we have discussed making the data interpolation configurable, were there ever a need.

Feel free to submit a pull request, or discuss further here.

[zoot-inge]

Thanks for this explanation and putting my attention to the right places.

I was expecting that the intermediate values (replicating, interpolating) would be based on this attribute. Maybe only when threshold limits and totals are logged this might go wrong.

• Not sure if and how often threshold limits are used in practice.
• For representation instances (totals listed in _numericRepresentationTotals), the value is set to 0. Can you explain why?

[kelly-nelson]

The interpolation code already existed when I started working with the plugin several years back, and I haven't spent much time with it (other than noting that it appeared to work well enough).

It appears that _numericRepresentationTotals contains a hardcoded list of representations for which the implementer wanted to avoid repeating a value and preferred to zero out the value. If indeed that is what is desired on totals DDIs, I agree that parsing the bitflags on DPD@D seems like a preferable approach.