860   Report example should not suggest a data-set configuration that will lead to data tearing

This tissue has following status: green

Created: 28 Jun 2012

Links:

Page: 108

Clause: 17.2.3.2.2.9 Entry

Paragraph: Example for Figure 32 - Data set members and repor

Category: No impact on this part

Issue: In this example the Value, Quality and Timestamp for MyLD/XCBR1.Pos is configured in the TestRpt1 data-set in the following manner:

MyLD/XCBR1.Pos.stVal
MyLD/XCBR1.Pos.q
MyLD/XCBR1.Pos.t
...

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
?
Ballot until Editor
12 Apr 13 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 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 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.
28 Jun 12 red

 

Privacy | Contact | Disclaimer