VQT values generally need to be treated as an atomic unit. If a data-set is configured in the way described in this example, separate reports will deliver the information that describes a single event. The client will then not be able to to deterministically re-create the single update; which will lead to the event being ignored, or the possibility of data-tearing (value with wrong timestamp or quality).
Proposal
Add a clarifying note such as:
NOTE: Value, Quality and Timestamp data attributes should not be specified separately in a data-set in practise. Doing so will prevent a client from being able to match the value, quality and timestamp for a specific event.
Discussion
Created
Status
12 Apr 13
In Force (green)
Fig 32 states in the FCDA use case that "stVal and t changed, only stVal change produces internal notification". That means that t change doesn't.
The fact that VQT shall always deliver a snapshot of a status / measurand is not a reporting issue. It is defined in 7-3 (see attribute definition of q, and t in semantic table).
If V and Q changes at the same time (e.g. at substitution), there shall only be 1 report that report the change of V and Q. Using 2 reports (one for V and one for Q) would report a state that does not exist in the application.
The issue is interesting, but should not be a reporting issue, but a data consistency issue. This could be reinforce in 7-3 or 7-1.
09 Aug 12
Discussion (red)
I agree that this issue relates only to when a dataset is bound to a report and is not a general dataset definition issue. "This is an implementation issue to solve that a single event that leads in changing the value and the quality of an object, is reported in a single report." The issue with that is that this could only be solved device side, and you would also need to add the timestamp for a VQT event(which does not fit with the trigger option concept). In practise a client must consider this configuration invalid for a report as it cannot know that the device will package the VQT in a single report unless the dataset member is defined at the higher level.
The example usefully explains how data from a dataset will be reported, I just think a small clarification would help avoid confusion. More generally, the concept of VQT atomicity does not seem to be addressed in the standard and as a result this example is confusing when trying to develop a solution that avoids data-tearing.
29 Jun 12
Discussion (red)
Figure 32 illustrates how the report mechanism and the dataSet definition are bound. Typically, dataSets associated to GOOSE messages will have fcda as dataSetMembers, whereas dataSets associated to Report messages will have fcd as dataSetMmmbers (otherwise t, and other attributes without trigger option will only be reported at GI and Integrity).
"Seperate reports will deliver the information that describes a single event" - the concern here is that the event changes the value (dChg) and the quality attribute (qChg). This is an implementation issue to solve that a single event that leads in changing the value and the quality of an object, is reported in a single report. This is not a dataSet definition issue.