R1007 breaks use cases with multiple Subscriptions

[ben-Draeger]

Section Number

Section 3:8.3.2.12.1

Priority

• Medium: Significant issue or clarification. Requires discussion, but should not lead to long debate.

Issue

Requirement R1007 ensures that a SOMDS Provider will never send two Reports (of the listed ReportTypes) with the same mdibVersion. However, to the best of my understanding, the BICEPS standard does not limit the subscriptions a Consumer can make.

Consider the following case:
A Consumer connects to a Provider using the SDC protocol and makes 2 subscriptions for the same ReportType (say: msg:EpisodicMetricReport). Now, an AbstractMetricState in the Providers Mdib changes. As far as I understand, the Provider is now required to send the same Report (the one updating the AbstractMetricState) to the Consumer twice - one for each Subscription.
However, this behaviour violates the Requirement R1007.

What is the Provider supposed to do in this case?

Proposed Change

An elegant way of solving this issue would be to adapt the Requirement R1007 to clearly state that the mdibVersion shall be strictly increasing within each subscription - this would still allow the Provider to send the same Report twice when the two Reports belong to different subscriptions.

[ToddCooper]

SDPi Friday 2024.06.28 Review - Need to investigate whether or not this is a true problem and if so, what the priority and change should be. @d-gregorczyk will investigate.

[d-gregorczyk]

Confirm, is a minor issue. The requirement can be rephrased such that it is more concise. Proposal:

Within an MDIB sequence, a SOMDS Provider shall send msg:DescriptionModificationReport, msg:ObservedValueStream, msg:WaveformStream, msg:EpisodicAlertReport, msg:EpisodicComponentReport, msg:EpisodicContextReport, msg:EpisodicMetricReport, and msg:EpisodicOperationalStateReport messages with a strictly increasing msg:AbstractReport/@MdibVersion per subscription.

[ToddCooper]

SDPi Workshop #4 -

@d-gregorczyk Status of this change?

[d-gregorczyk]

Should be fixed in 2.0.