"Time when the last service SelectActiveSG has been processed successfully"
This means that updating this attribute is only related to the SelectActSG service.
However, in fact, switching of setting group can also occur in ways that are outside of this standard (for example., using a switch connected to the digital inputs). Obviously, in such cases, the ActSG attribute should also change, but the LActTm timestamp will remain the same, continuing representing a time of the last SelectActiveSG service result.
I think this attribute would be more useful from a practical point of view if it represents the actual switching time of the active setting group.
Proposal
Expand the explanation so that LActTm should change whenever the ActSG attribute actually changes.
Discussion
Created
Status
6 months over
30 Nov 22
In Force (green)
batching of tissue has been circulated 57/2445/INF
Move to mustImplement:
Change text for LActTm in Table 62:
Time when the last activation of a setting group occurred: this includes:
- the time when the last service SelectActiveSG (even when specifying the "active" setting group) has been processed successfully,
- the time when the ActSG has changed by internal means,
- the time when the last service CnfEdit of the edition of the "active" setting group has been processed successfully.
01 Feb 22
Must Implement
Ballot expired - moved to solution accepted - wait for batch
16 Mar 21
Solution Accepted
Test case verified
16 Feb 21
Ballot Period
No backwards compatibility issues found as LActTm could always change without interaction from the observing client - for example if another client changed the ActSG as tracking is not mandatory and not available in Ed1 - no client should assume that this information will be presented.
25 Nov 20
Conformance Test Preparation
Change text for LActTm in Table 62 to reflect draft implementation:
Time when the last activation of a setting group occurred: this includes:
- the time when the last service SelectActiveSG (even when specifying the "active" setting group) has been processed successfully,
- the time when the ActSG has changed by internal means,
- the time when the last service CnfEdit of the edition of the "active" setting group has been processed successfully.
25 Nov 20
Analysis Of Compatibility
Time when the last activation of a setting group occurred: this includes:
- the time when the last service SelectActiveSG (even when specifying the "active" setting group) has been processed successfully,
- the time when the ActSG has changed by internal means,
- the time when the last service CnfEdit of the edition of the "active" setting group has been processed successfully.
11 Nov 20
Verify Draft Implementation
set to draft implementation
24 Sep 20
Drafting Implementation
Agree with Christoph that the change of semantic is probably not a "real" problem, but there is no harm to adding a new attribute, so I will support that solution.
21 Jul 20
Discussion (red)
I think the subject of backward compatibility occurs in one of two cases:
- a single MMS client switches actSG and checks the LActTm value for some reason;
- someone tracks a time of the last remote switching the actSG separating remote switching from the local one.
By the way, for the 2nd case, the current semantics of LActTm can be useful. Because the remote control is the best way to perform dangerous switching within a substation.
14 Jul 20
Discussion (red)
I would support the proposal of Bruce not changing existing semantics. Creating a new optional attribute with semantic "Time of Last Setting Group Change" which would always update when LActTm updates, would also allow to be sent via MMS reporting or GOOSE in addition...
14 Jul 20
Discussion (red)
Changing existing semantics should be a last resort. It would be better to create a new optional attribute with semantic "Time of Last Setting Group Change" which would always update when LActTm updates.
13 Jul 20
Discussion (red)
I think we should start discussing this Tissue and decide on a solution
13 Jul 20
Discussion (red)
I do not really see a reason, why a client should depend on the fact that LActTm does not change without an explicit request to change it.
In fact, a client1 already today needs to deal with the possibility, that LActTm changes spontaneously from the view of the client1 - in case another client2 has changed the setting group. For client1, there is no visible difference if client2 or if "local means" change the setting group.
So apparently no backwards compatibility issue and I would propose to accept the proposal.
17 Jun 20
Accepted
The current semantic for LActTm has not changed since First Edition. Clients might depend on the fact that LActTm does not update when a server changes ActSG by "local means".
The "actual" value appears in SGCB service tracking STS.actSG.
Perhaps we could add a requirement that STS be implemented whenever a server can change the value of ActSG "by local means".
Alternatively, a client could periodically poll SGCB.ActSG.
Any change to the semantic of LActTm will result in needless backwards compatibility issues.