TmSyn is defined in 7-2 Clause 6 as:
ENUM with 0 = external, 1 = local , 2 = global sync.
"According to IEC 61850-9-2"
However, in <EnumType id=TmSyn," 0 is unsynchronized.
which has another definition.
in 5.3.9 it is defined as "refers to IEC 61850-9-2"
IEC 61850-9-2 does not define TmSyn. The closest is SmpSynch,
which is an INT8U enumerated, with 0 = unsynchronized, 1 = local, 2 = global, 3,4: undefined. and 5-254: value of the master clock short ID.
This information cannot be made accesible to ACSI.
Further, one should not use type definitions from a SCSM in 7-2, which is protocol-independent.
IEC 61850-7-2 19.4.8 contains a definition of SmpSync which is not mapped to 9-2.
here, 0 = not synchronized by an external clcok
Proposal
Define TmSyn in 7-2 uniquely, with the same definition as SmpSynch
in 9-2. 0 = unsynchronized and 5..254 = ShortMasterId.
Discussion
Created
Status
11 Dec 13
Future Improvement
The values of the enum of TmSyn should be:
0= SV are not synchronised by an external clock signal.
1= SV are synchronised by a clock signal from an unspecified local area clock.
2= SV are synchronised by a global area clock signal (time traceable).
3= reserved
4= reserved
5= SV are synchronised by a clock signal from a local area clock identified by 5
6= SV are synchronised by a clock signal from a local area clock identified by 6
...
254= SV are synchronised by a clock signal from a local area clock identified by 254
255= do not use
INS will be not possible because in 7-3 CDC INS defines INT32 (to big range).
22 Mar 13
Discussion (red)
We could extent the enum value list for ShortMasterID (5...254). Than we have to add these vaules in the semantic description table.
Before that we have to change part 9-2 and/or 7-2 to make them consistent with 7-4.