Project

General

Profile

Support #492

(a) If a device does not support configuration of the ctlModel for a specific DO – what is the correct way to declare this? • De

Added by Herbert Falk about 3 years ago. Updated almost 2 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
-
Start date:
Due date:
% Done:

0%

Estimated time:
ID:
7
Source:
IOP_2015
TF Unique ID:
7 # IOP_2015
WG10 Proposal:

Refer to TISSUE 1447

Estimated Completion:
Discuss in Upcoming Meeting:
To discuss in WG10:
Short Proposal:

If not writable outside of ICT/IED, then it is optional to restrict the set of values. If restricted can deal as documentation only.
A DA is writable if
- it is a control service parameter, OR
- configuration DA (FC={SP,SE,CF}), and ( valKind!=”RO” OR valImport=true )
If writable, then only the supported enum values shall be included (i.e., EnumType MUST be restricted). Applies to DA level (of course restricted EnumType can be reused).
Are there exceptions, special cases? (Concern: SCL file size may increase.)
- Identified exceptions: SIUnitKind, MultiplierKind.
=> TISSUE to be written by… Herb!

Standard(s):

6

Needs More Information:
Assigned TF:

Description

(a) If a device does not support configuration of the ctlModel for a specific DO – what is the correct way to declare this?
• Declare the DA as RO in SCL and configure a value (e.g. direct operate)
• Provide in the data model for that DO only the attributes required for the supported model (e.g. oper)
• Both of the above? And what if they disagree?
(b) If a device supports configuration of ctlModel, but does not support all variants
• Define the restrictions in a enum type, that is only applicable for all DOs that have the same constraint
• Provide in the data model for that DO only the DAs that are required for the supported model. Note that with that, you could not really define that a variant that is a subset (e.g. direct operate if SBO is supported as well), is not supported.
• Do a combination of above; e.g. define a enum type status only, sbo. Define the data model for some of the DOs that has oper and sbo DAs (this DO allows status only and sbo); and for some others, a data model that has none of the control attributes (this DO will be status only). Note: again, with that approach it may not be possible to support all variants.
• If restrictions are defined through a enum type, does the data model need to match the restriction (e.g., if a DO is defined with a specific enum type to support status only, is it forbidden to have oper in the data model?)

ENUMTYPE:
Declaration of enum types:
If a device does not support all possible values of an enum type (e.g. LN Mode ON-BLOCKED not supported), but it has no private additional values (extensions), it is allowed to define a enum type in the SCL file (data type template section) that is a subset of the standardized type.
- is it allowed or is it required to define a enum type that only includes the subset?
- In case it is required, does it need to be made for each usage of the enum type in a DO where it is different? With other words: assume some controllable DOs (e.g. of CDC SPS) allow only direct control without enhanced security; other DOs (e.g. of CDC DPS) allow only select before operate with or without enhanced security. Is it required to define two enum types or is it sufficient to define one that includes direct control without enhanced security, sbo without enhanced security and so with enhanced security. What in the case of units, when we have one DO that is currents (and apparently only SIUnit Amp applies) and another one that is PhV (and only Volts apply)?

#1

Updated by Carlos Rodriguez del Castillo almost 2 years ago

  • Status changed from New to Closed

Confirm to IEC 61850-6 editor that this issue has been accounted for.

Also available in: Atom PDF