IEC 61850 7-2 defines an attribute type call PHYCOMADDR.
IEC 61850-6 includes PhyComAddr in the basicTypes.
IEC 68150-8-1 defines PhyComAddr as an structure.
Within the SCL example in IEC61850-7-2, using the line:
Up to the definition of PhyComAddr, only the DA elements using bType "Struct" could have childrens in the information model structure.
The second SCL approach does not require any change in the MMS stacks.
From the IED device model developer, can we use the second approach?
Thank you for your clarification.
Proposal
Discussion
Created
Status
With an SCL 2007B and lower, the only possibility is to use the bType PhyComAddr in the DataTypeTemplate
<DA name="dstAddress" bType="PhyComAddr" fc="SR"/>
With an SCL 2007B2 or higher, both
-bType="Struct" with associated DaType
-bType="PhyComAddr" are possible
are possible.
At the end, the GTS instance that is used for tracking the GOOSE access shall use the data model that is consistent with the transport used: Layer 2, or UDP/IP.
As routable capabilities are introduced with Ed2.1 of 8-1, there is no interop issue to expect. Clients shall be aware of the type abstraction when PhyComAddr in used in the DataTypeTemplate of a server, that the real model in the device will be determined by the transport used for the realisation of multicast association
09 Feb 16
In Force (green)
For Ed2.0 the myPhyComAddr DAType structure will result in SCL schema validation errors. Thus only the bType option is allowed for Ed2.0. In the SCL environment the bType="PhyComAddr" (not PHYCOMADDR).
This is the correct SCL:
<DA name="dstAddress" bType="PhyComAddr" fc="SR"/>