Closed alaendle closed 5 years ago
ameinhardt
commented
5 years ago Hi @alaendle , Please see the discussion from @bf-bryants https://github.com/eclipse/unide/issues/33#issuecomment-384704959 and @bgusach https://github.com/eclipse/unide/issues/33#issuecomment-385352517 who argued that your force and distance would have a time measure to it. Otherwise, it's not a real measurement, but rather a statistic. What do you think?
alaendle
commented
5 years ago Well I agree about the conceptional shift of the unide format (see also @bf-bryants comment and my statement on the referenced issue #40); however I like to disagree that this is not real measurement - for me a measurement is simple a quantitative proposition of a characteristic of something to a unit. The time of the measurement might or might not be interesting/relevant - e.g. the measurement is constant; or I'm just interested in the relationship to another measurement.
O.k. this was more a theoretical viewpoint, to be pragmatic and delivery an explanation why I've created this issue. We really have implementations of measurements where we couldn't provide a real exact timestamps. Let me explain: While sensor cards for sure deliver qualified timestamps, we also have implementations on (rather slow/imprecise) control systems which just watch a specific value - and if that value changes more than a specific amount another measured values is taken and both values are written to the log. This way we collect some displacement/force tuples.
If we are forced to provide a timestamp - which is unneeded here anyway - we may produce more trouble than value. Chances are good that totally absurd values will be written to the unide telegram to just fulfil the format specification - e.g. just the enumeration of the tuples like 0, 1, 2, 3, 4 - because a change to the control systems to just produce an needless timestamp value series is unlikely to happen. But even if the control system is changed to provide a timestamp it might produce more harm than good, because the resolution/synchronization of the time on the system might be too imprecise. Also since the timestamps are not equidistant chances are higher on 3rd party systems that the other series are somehow normalized on time based rates and so additional numerical problems might occur - but this is speculation.
To turn it the other way around - what are the use cases where a mandatory time field has an advantage? Because the same argument of the 100 meter pipe (see https://github.com/eclipse/unide/issues/33#issuecomment-385352517) is true for time stretched measurements - you could have different telegrams if another systems is really forced to create a conjunction between the measured series and the timestamp of the measurement. Lets think of a meteorological station that transmits the outside temperature every second - and we want to support a continuous analysis. So would we like to represent this as a huge telegram every hour? Or do we expect a telegram with a single value every second? Or do we need to support both use cases? If we have no special series representing the time we are forced to send a single telegram every second - which is fine from a streaming or latency standpoint, nut might be unwanted because of the huge redundancy. But if we submit multiple temperatures in a single telegram we need a special series representing the time (in the meaning of Wallclock - we also might also have other timestamps - maybe because I'm a computer scientist CPUtime comes to my mind ;-) ).
So I think the smallest compromise could be to declare an optional special time series (maybe just by naming convention) - which means basically no change to v2.
A more crafty solution could try to map the requirement on a optional Wallclock time to the general unit problem #44 - but I fear this needs additional brainpower, because it would extend the already huge problem of unit specification (which is at least somehow standardized and (at least partially) solved at other systems we can look at) to the much wider uncertainty of semantic interpretation measured metrics.
ameinhardt
commented
5 years ago With https://github.com/eclipse/unide/commit/54482bfd23d5b677d94efd95f525f60f9a8e5cfc, the 'time' offset for process messages should be optional, for measurements it's still mandatory. That would also be reflected in process payload diagram and the measurement payload diagram. Any objections?
alaendle
commented
5 years ago This would be sufficient for our immediate requirements, thanks.
In general I still believe that a measurement (series) is not necessarily is time dependent - e.g. a measurement of a colour gradient (might have a position/length-dimension and an axis specifying the colour saturation). So I would still vote for a complete optional time series in process and also in (pure) measurement telegrams.
In addition to this this I couldn't find a good explanation why a time series in a process is optional while it is mandatory for a measurement event.
For a process depending on a time is just unnecessary - e.g. we have process results that represent a force-distance characteristics. So I just need two series (one for force and one for distance) to represent the process - even if the process/measurement is chronological, we have no timestamps for the concrete force/distance pairs.
And I guess we can imagine a lot of other processes where their is no direct time reference. So please reconsider if it is useful for a generic format to force a time reference for every measurement (maybe there was a reason why this field was optional in v2?).