search

ADAPT / ISOv4Plugin

Eclipse Public License 1.0
18 stars 34 forks source link

TriggerMethod not used (?) #113

Open zoot-inge opened 4 years ago

zoot-inge commented 4 years ago

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.

knelson-farmbeltnorth commented 4 years ago

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 commented 4 years ago

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.

knelson-farmbeltnorth commented 4 years ago

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.