1322   SetBRCBValues - one or multiple?

Created: 20 Oct 2014

Status: Not Applicable

Part: Part 7-2 (2010; Edition 2)

Links: #1336 enhanced the mapping text for the setValues.

Page:

Clause: 17.2.3.4.1

Paragraph: SetBRCBValues parameter table

Category: No impact on this part

Issue

17.2.3.4.1 SetBRCBValues parameter table

Is it allowed that a Server accepts to set only single RCB (LCB, ...) Attributes in one service request? That means the Server will reject all requests that carry more than one attribute.

Example in the “Conformance Test Procedures for Server Devices with IEC 61850-8-1 Edition 2 interface” follows:
---------------------
Testcase: sBrN2 - Only trigger option GI

Configure an available BRCB using SetBRCBValues with all supported fields, BufTm=0, IntgPd=1000 and only trigger option general-interrogation.
---------------------
There are many testcases that apply SetBRCBValues …

The configurations in sBrN2 could be implemented by a single SetBRCBValues with four (4) attributes, two with two each, … or four (4) SetBRCBValues with a single attribute.

My guess is that a server is conformant only if it accepts SetBRCBValues with a single attribute per request.

The standards defines currently:

“SetBRCBValues.request shall be processed atomically by the server. If the request contains any parameters, whose sets fails, a Response– shall be returned.”

First we need to define what atomically really means! I guess it means: you cannot process the service partially … if you want to set two (2) attributes a and b, and a fails, you cannot set b and respond that b is ok but a is not!!

In order to know which attribute caused a problem, you have to set a single attribute!!!! I guess this is what we need to get! There is no partial success! Either it works or it does not!

Proposal

We need to define 100% how it SHALL work … not how it may work!

In “17.2.3.4.1 SetBRCBValues parameter table” it should be specified that only a single attribute shall be set with one service request.

Discussion Created Status
Ntp - This is a mapping issue.
Will be resolved in 1336.
08 Dec 14 Not Applicable
I agree to the proposal to enhanced the mapping text for the set<CB>Values in 8-1 Ed2.1. Both ways of doing the MMS write Request (described by Thierry Dufaure) will give specific accessResults, which allows it to identify the failing or succeeding brcbAttribute. 03 Nov 14 Discussion (red)
SetBRCBValue(BRCBRef, brcbAttribute1, value1) is mapped to a MMS write Request (BRCBRef.brcbAttribute1, value1).

SetBRCBValue(BRCBRef, brcbAttribute1, value1, brcbAttribute2, value2) is mapped to either
-> two MMS write Requests
(BRCBRef.brcbAttribute1, value1)
(BRCBRef.brcbAttribute2, value2)
it results in 2 write responses therewith with two accessResults.
-> a single MMS write Request ({BRCBRef.brcbAttribute1, value1}, {BRCBRef.brcbAttribute2, value2}) equivalent to 2 writes as the MMS write response will have 2 accessResults.

in both case, it is clear that the MMS mapping provides only access to single attributes, and the number of accessResult shows how many SetBRCBValue were in deed perofmred. This is a property of the mapping.

Proposal: 8-1 Ed2.1 - enhanced the mapping text for the set<CB>Values.
31 Oct 14 Discussion (red)

 

Privacy | Contact | Disclaimer

Tissue DB v. 23.12.13.1