I have a list of questions after analyzing Table 11:
1. Semantic of the SCL element <ReadWrite> isn't clear. It covers too many different Abstract Communication Services of 61850-7-2 (ACSI):
for LN -> GetAllDataValues;
for DO -> GetDataValues, SetDataValues;
for Setting Group -> GetEditSGValue, GetDataValues;
for Log -> QueryLogByTime (maybe I'm wrong), QueryLogAfter (maybe I'm wrong), GetLogStatusValues (maybe I'm wrong);
for Control -> Operate, Cancel (maybe I'm wrong), CommandTermination (maybe I'm wrong).
As a result: I don’t understand how I should map an Abstract Communication Services to <ReadWrite>.
2. It is not clear what Abstract Communication Services are related to SCL element <GSEDir>.
3. Why we haven't got analog of <GSEDir> for sampled values?
4. Why for specifying GOOSE and SV publisher we have SCL elements <GOOSE> and <SMVsc>, but for specifying REPORT publisher and LOG storage (on IED and AccessPoint level) - we haven't got SCL elements?
5. Why for specifying capability of static creation (via SCL) of REPORT control block and LOG control block we have SCL elements <ConfReportControl> and <ConfLogControl>, but for GOOSE and SV control blocks we haven't got similar SCL elements? Is it deprecated by 61850 to configure GOOSE/SV control blocks via SCL?
Proposal
1. To review description of <ReadWrite> element.
2. To add "services GetGoReference and GetGOOSEElementNumber" to description of <GSEDir>?
3. To create new SCL child element for <Services> (maybe <SMVDir>), which will relate to GetMsvReference and GetMSVElementNumber.
4. To create new SCL child elements for <Services>, which will specify that IED/AccessPoint could be REPORT publisher and LOG storage.
5. To create new SCL child elements for <Services>, which will specify capability of static creation (via SCL) of REPORT and LOG control blocks OR explain why we don’t need it.
Discussion
Created
Status
Approved Future
12 Dec 23
Future Improvement
Dear C. Bloch
Thanks for your explanation.
PICS Table A.1, A.2 and A.3 in 61850-7-2 is a great source of information about what models (and what their services) is mandatory/optional. Thanks!
Regarding definitions of the SCSM: thaks for the tip about table 82 in 61850-8-1 and table 64 in 61850-8-2.
But why we haven't similar tables in SCSM for other models (setting group, report, GOOSE, SMV)? Are there any reasons and explanation?
31 Jul 23
Approval (Future Improvement)
As complement to my previous answer, the requirement for Log services is not only from SCSM, but already in ACSI, as a statement in the PICS Table A.3 - S30 to S34, since first edition of part 7-2.
As soon as M10 Log is declared as supported, the S30 to S34 applies.
28 Jul 23
Approval (Future Improvement)
Dear A. Ivanov
Regarding Log services, they are all mandatory when logs are supported as per definition of the SCSM in 61850-8-1 ed2.1 in table 82 and also in 8-2 ed1 table 64. As soon as a future SCSM will make it optional we will have the requirement to describe this optional behavior of a device, and it will be taken into account at this time.
Regarding the dedicated services for SMV which should be missing, We will look at it when looking at the GSEDir which not be required anymore. We will probably have the same decision for SMV directory services.
This will be discussed in future edition of part 6.
27 Jul 23
Approval (Future Improvement)
C. Bloch
Thank you for your comment!
1 point: Could you explain this, please: "...there is no need to declare the support of Log services because they are MANDATORY...". I haven't found any explicit labels in 7-2, which indicate that services are mandatory/optional.
As an example: my SERVER could has opportunity to provide log entries selected by time (QueryLogByTime), but couldn't has opportunity to provide entries selected by entryID (QueryLogAfter). From my point of view, it is theoretically possible: 7-2 hasn't explicit requirement that ALL services are mandatory if SERVER supports Logs.
2 and 3 point: Ok, great!
And clarify, please, why we haven’t got similar SCL child element for SCL element “Services”, which will relate to GetMsvReference and GetMSVElementNumber (analogue of GSEDir for MSVCB class).
25 Jul 23
Approval (Future Improvement)
Dear A. Ivanov
Regarding your first point, there is no need to declare the support of Log services because they are mandatory if you support Logs in the server. So the declaration of ConfLogControl is enough to declare that you are supporting Log services. Service declaration is useful only when the service is optional in 7-2. which is the case for most of the GetValue/SetValue services, even if some are mandatory and so not concerned by the service declaration.
For point 2 and 3 this will have to be clarified what is behind GSEDir and if it is not redundant to the call to GetLogicalNodeDirector(GoCB).
04 Jul 23
Approval (Future Improvement)
Dear B. Muschlitz,
Thank you for your comment!
1. Using SCL element “ReadWhite” to indicate, that server is capable to respond to services GetAllDataValues, GetDataValues, SetDataValues, GetEditSGValue, GetDataValues – OK, it is obvious.
About Log: But what about services QueryLogByTime, QueryLogAfter, GetLogStatusValues (part of services start with “Query”, not by “Get”)? Should I use SCL element “ReadWhite” to indicate, that a server could provide online logs to client? And what about a situation, if my server can respond to services GetAllDataValues, GetDataValues, SetDataValues, GetEditSGValue, GetDataValues, but can’t respond to services QueryLogByTime, QueryLogAfter, GetLogStatusValues? How can I define this situation by SCL element Services?
About Control: The definition of SCL element “ReadWhite” include service Operate. But what about Cancel and CommandTermination? Cancel and CommandTermination are covered by SCL element “ReadWhite”? And similar situation: if my server can respond to services GetAllDataValues, GetDataValues, SetDataValues, GetEditSGValue, GetDataValues, but can’t process services Operate, Cancel and CommandTermination - how can I define this situation by SCL element Services?
2. I did’t understand your comment. The server ability to respond to ACSI GetLogicalNodeDirectory is presented by SCL element “GetDirectory”. As I understand 61850-6 ed. 2.1, table 11 and 61850-7-2: SCL element “GetDirectory” indicate that you can get instance name of ANY type of information entity from server (Data object, DataSet, BRCB, URCB, LCB, LOG, SGCB, GoCB, GsCB, MSVCB, and USVCB). There's no need to further specification for GoCB.
SCL element “GSEDir” indicate that server is capable to respond to GetMsvReference and GetMSVElementNumber. But we haven’t got similar SCL child element for SCL element “Services”, which will relate to GetMsvReference and GetMSVElementNumber. Why???
3. see my comment 2 above.
4. I have re-read 61850-6 ed. 2.1 Table 11 – YES, this doesn’t seem missing:
SCL element “ConfReportControl” (and preconfigured SCL elements “ReportControl”) show, that IED/AccessPoint could be REPORT publisher;
SCL element “ConfLogtControl” (and preconfigured SCL elements “LogControl”) show, that IED/AccessPoint could be LOG storage.
From my point of view, SCL elements “ConfReportControl” and “ConfLogtControl” are more appropriate to indicate, that IED/AccessPoint could be REPORT publisher or LOG storage. SCL elements “ReportSettings” and “LogSettings” are used to detail configuration of RCBs and LCBs.
5. I have re-read 61850-6 ed. 2.1 Table 11 – YES, this doesn’t seem missing:
SCL element “GOOSE” specify capability of static creation (via SCL) of GOOSE control blocks;
SCL element “SMVsc” specify capability of static creation (via SCL) of SV control blocks.
Misunderstanding has happened because of different type of names: SCL elements “CONFReportControl”, “CONFLogtControl” (start with CONF) and just “GOOSE”, “SMVsc”.
03 Jul 23
Approval (Future Improvement)
1. ReadWrite is clear enough, addressing all ACSI services related to read and write value as soon as the related service (GOOSE, Report, Control, ...) is supported and declared by the device. So for example, if you implement GOOSE, the corresponding ACSI services are GetGoCBValues and SetGoCBValues.
2. GSEDir needs to be clarified, and maybe made obsolete as it seems to be redundant with GetDirectory. This is an evolution for Edition 3.
3. To be coupled with point 2
4. ConfReportControl and ConfLogControl are the services to declare the support of Report and Log. Do you see any other missing declaration?
5. The different services related to creation of control blocks exists and are related to static creation in SCL. For each kind of control blocks we have 2 kind of service element: creation and setting:
- for Reports: ConfReportControl + ReportSettings
- for Logs: ConfLogControl + LogSettings
- for Gooses: GOOSE + GSESettings
- for Sampled values: SMVsc + SMVSettings
The capability to create/delete control blocks by an SCT is given by the combination of the two elements as defined in ed2.1.
To summarize, only the GSEDir needs to be clarified or removed if no more required. And this will be looked for next edition.
We may look if we improve also the ReadWrite service to give example.
03 Jul 23
Approval (Future Improvement)
My personal comments:
1. ReadWrite is clear: If the server is capable to respond to at least one of GetData and SetData for at leat one DO then ReadWrite should be present. (I have never seen a server which does not declare ReadWrite)
2. GSEDir is the ability to respond to ACSI GetLogicalNodeDirectory(ACSIClass=GoCB) (see 61850-7-2 clause 10.2.2).
Note that MMS GetNameList is the underlying service which is mandatory anyway for Service=GetDirectory
3. This does seem missing. However, it would probably be redundant because it is implied by GetDirectory with SMVsc
4. I do not understand. Service/ReportSettings and Services/LogSetting does exist
5. I do not know